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FOREWORD 


This  technical  report  covers  work  performed  under  Air  Force  Contract  F33600-X7-C-0464,  DAPro 
Project.  This  contract  is  sponsored  by  the  Manufacturing  Technology  Directorate,  Air  Force 
Systems  Command,  Wright-Patterson  Air  Force  Base,  Ohio.  It  was  administered  under  the 
technical  direction  of  Mr.  Bmce  A.  Rasmussen,  Branch  Chief,  Integration  Technology  Division. 
Manufacturing  Technology  Directorate,  through  Mr.  Dtwid  L.  Judson.  Project  .Manager.  The 
X.Prirn«^  Contractor  was(lntegration  Technology  Services,/Software  Programs  Division,  of  the 
Control  Data  Corporation,  Dayton,  Ohio,  under  the  direction  of  Mr.  W.  A.  Osborne.  The  D.APro 
Project  Manager  for  Control  Data  Corporation  was  .Mr.  J.  P.  .Vlaxwell. 

The  DAPro  project  was  created  to  continue  the  development,  test,  and  demonstration  of  the 
Integrated  Information  Support  System  (IISS).  The  IISS  technology  work  com|uises 
enhancements  to  IISS  software  and  the  establishment  and  operation  of  IISS  test  beti  harduare  and 
communications  for  developers  and  u.sers. 

The  following  list  names  the  Control  Data  Corporation  subcontrtictors  and  their  contributing 
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SECTION  1 
INTRODUCTION 


1.1  Background 

In  September  1989,  Control  Data  awarded  subcontracts  to  IBM  Corporation  and  .Northrop 
Corporation  for  the  Enterprise  Integration  Framework  task.  This  document  presents,  as  an 
unedited  appendix,  the  IBM  Workshop  Briefing.  DAPro  document  EIF  620350001  provides  the 
final  repon  of  the  Northrop  effort. 

1.2  Disclaimer 

The  conclusions  pre.sented  by  this  document  are  those  of  the  IBM  EIF  Team  and  do  not 
necessarily  reflect  those  of  either  Control  Data  or  WRDC/MTI.  The  release  of  this  document  does 
not  imply  endorsement  by  the  USAF. 
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SECTION  2 
EIF  OBJECTIVES 


2.1  WRDC/MTI  Statement  of  Work 

In  June  1990,  WRDC/MTI  released  a  SOW  defining  the  Enterprise  Integration  Framework 
task.  A  simplified  version  of  that  SOW  is  presented  in  this  section. 

2.1.1  Background 

The  Integration  Technology  Division  of  WRDC/MTI  and  their  cosponsors  will  be  leading 
an  effort  to  define,  develop,  and  validate  through  implementations  a  national  framework  for  inter 
and  intra  enterprise  integration  based  on  open  systems  and  national  and  international  standards. 
This  effort  will  be  cospon.sored  by  the  Defense  Manufacturing  Office  of  the  Defense  .Advanced 
Research  Projects  Agency  (DARPA  DM0),  the  Computer  Aided  Acquisition  and  Logistics  Support 
(CALS)  office  in  the  Office  of  the  Secretary  of  Defense  (OSD  CALS),  and  the  National  Institute 
for  Standards  and  Technology  (NIST).  This  effort  will  begin  with  a  preliminary  strawman 
framework  development  task  to  serve  as  the  catalyst  for  national  debate  and  involvement  in  follows - 
on  longer  temi  programs  for  the  development  and  implementation  of  open  systems  for  enterprise 
integration.  It  is  anticipated  that  a  national  consensus  will  emerge,  resulting  in  a  United  States 
model  for  the  development  of  international  standard(s)  for  integrating  many  types  of  applications 
and  indu.stries.  Opportunities  will  be  sought  for  cooperation  and  coordination  with  other  related 
international  effons. 

This  task  for  development  of  a  preliminary  or  strawman  enterprise  integration  framework 
will  build  off  of  prior  and  ongoing  work  including  the  European  Strategic  Program  for  Research 
on  Information  Technology  (ESPRIT)  consortium  developing  a  Computer  Integrated 
Manufacturing  Open  Systems  Architecture  (CIM  OSA).  For  a  number  of  reasons,  the  United 
States  has  been  slow  to  respond  in  a  unified,  coordinated  manner  to  this  activity.  To  facilitate  the 
design  of  a  comprehensive  enterprise  integration  framework,  the  approach  of  this  task  is  not  to 
Stan  from  scratch,  but  to  evaluate  the  relevance  of  leveraging  the  ESPRIT  CIM  OS.A  effort  as  w  ell 
as  other  potentially  relevant  e-sisting  initiatives.  The  resulting  framework  will  provide  a  stable, 
low-risk  strategy  for  coordinated  investment  by  guvernment  and  industry  in  automated 
infrastructures.  The  framework  will  also  provide  a  common  reference  model  for  esttiblishing 
research  priorities,  modernization  of  DoD  activities,  and  sttindtirds  etforts.  .A  number  of  elosel} 
coordinated  activities  of  the  sponsors  will  support  the  development  td'  the  national  framework 
initiated  by  the  strawman  framework  from  this  effort. 

2.1.2  Scope  of  Effort 

This  enterprise. integration  strawman  framework  effort  shall  span  an  eight  month  time 
period.  There  will  be  two  tasks  executed  serially:  task  one  shall  last  two  months,  task  two  shall 
last  six  months.  The  objective  of  the  effort  is  to  employ  contractor  expertise  to  work  closely  w  ith  a 
NIST-led  Framework  Advisory  Board  (FAB)  to  quickly  assess  the  state  of  the  art.  de\eU'|i  a 
stntwman  framework,  and  perform  a  domain  imp:ict  study  for  the  framework.  While  the  focus  I’l 
the  effort  is  primarily  domain  independent,  the  contractor  shall  focus  primarily  (but  not 
exclusively)  on  aerospace  enterprise  issues  to  include  an  aerospace  organization's  interfaces  to  the 
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government  and  to  subtler  suppliers.  Task  1  should  not  exceed  25%  of  the  total  effort;  task  2  shall 
compose  the  remainder  of  the  effort. 

2.1.3  EIF  Tasks 

Task  1 :  Preliminary  Scoping  Document  and  Development  Plan 

1 . 1  The  contractor  shall  submit  a  monthly  status  project  status  letter  to  the  AFP.VIO  to 
identify  significant  events,  accomplishments,  contractor/government  liason  activities/meetings. 
potential  problem  areas  or  issues,  and  related  progress  throughout  this  effort.  The  contractor  shall 
use  the  IDEF  methodologies  and  other  formal  structured  techniques  as  required  for  reporting 
results  when  appropriate.  The  contractor  shall  develop  and  document  a  management  plan  tor 
performing  the  activities  of  task  1  and  task2. 

1.2  The  contractor  shall  develop  an  unclassified,  annotated  bibliography  and  assessment  of 
existing  material  which  is  relevant  to  the  framework  development.  Using  this  source  material,  the 
contractor  shall  extract  a  list  of  requirements,  issues,  measurement  criteria,  and  sources.  The 
contractor  shall  provide  input  to  the  NIST-led  FAB  in  order  to  develop  a  single  clear  mission 
statement  and  criteria  for  evaluating  the  success  of  the  framework  strawman. 

1.3  The  contractor  shall  develop  a  list  of  enterprise  processes,  building  a  matrix  show  ing 
how  each  process  contributes  to  mitigating  the  issues  in  achieving  enterprise  integration.  The 
contractor  shall  build  a  list  of  information  classes  for  each  process.  The  contractor  shall  develop  a 
glossary'  of  enterprise  integration  terminology  to  submit  to  the  FAB  and  assist  in  the  de\  elopment 
of  a  single,  consistent  glossary  to  be  finalized  by  the  F.AB. 

1.4  The  contractor  shall  participate  as  authorized  by  the  .AFP.VIO  in  government  led  and 
sponsored  discussions  with  national  and  international  organizations  such  as  ESPRIT. 

1.5  The  contractor  shall  evaluate  the  ESPRIT  CIM  OSA  work  and  any  other  relevant 
initiatives  identified  in  subtask  1.2,  and  make  recommendations  on  (a)  using  CI.VI  OSA  terms  and 
definitions  in  the  framework  and  in  the  enter-prise  integration  glossary,  (b)  extensions  to  ClM 
OSA  reference  architecture  needed  to  address  the  issues  identified  in  subtask  1.2,  and  (c)  using  the 
extended  CI.VI  OSA  reference  architecture  to  populate  the  framework  processes  in  task  2. 

1.6  Using  the  results  of  the  previous  subtask,  the  contractor  shall  develop  an  EIF 
development  plan  for  defining  a  strawman  framework  interms  of  requirements,  issues,  enterprise 
processes,  and  information  types  in  task  2. 

1.7  The  contractor  shall  present  the  results  of  task  I  and  the  FIF  development  pl.ui  .it  ,i 
government  sponsored  workshop.  Formal  approval  of  the  plan  shall  be  provided  by  tlie  .\1PNU) 
prior  to  the  execution  of  task  2. 

I'ask  2:  Development  of  a  .Strawman  EIF 

2. 1  The  contractor  shall  develop  a  strawman  framework  for  enterprise  integration  Ixised 
upon  open  systems  concepts  and  national  and  international  standards.  The  contractor  shall  update 
the  glossary  and  submit  it  to  the  AFP.VIO  to  be  finalized  by  the  F.AB. 

2.2  The  contractor  shall  provide  a  report  analyzing  the  potential  impact  of  .in  .ipprovcd 
framework  on  current  programs.  Recommendations  on  the  methotls  of  using  the  framework  iii 
these  programs  and  anticipated  benefits  as  well  as  negative  impacts  shall  be  liescribed.  I'lie 
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example  matrix  of  subtask  1.3  shall  be  employed,  showing  how  detailed  process  elements  in  these 
candidate  programs  map  to  the  strawman.  The  following  programs  shall  be  considered: 

Product  Data  Exchange  using  STEP  (PDES) 

DARPA  Initiative  in  Concurrent  Engineering  (DICE) 

Microelectronics  Manufacturing  Science  and  Technology  (MMST) 

Integrated  Composite  Center  tICC) 

Integrated  Design  Support  (IDS) 

Advanced  Cost  Management  Systems  (ACMS) 

Automated  Airframe  Assembly  Program  (AAAP) 

any  other  suggested  program(s) 

2.3  The  contractor  shall  produce  and  deliver  a  final  Strawman  EIF  which  shall  be  prepared 
in  contractor  formats.  The  contractor  shall  present  the  strawman  framework  at  an  end  of  ta.sk 
briefing  to  the  AFPMO  and  their  cosponsors  and  selected  audiences  specified  by  the  F,\B  and 
conveyed  in  writing  by  the  AFPMO.  The  contractor  shall  clearly  identity  all  open  issues  and 
alternatives.  The  contractor  shall  present  and  deliver  the  results  of  this  effon  to  the  AFP.MO  via  the 
Prime  Contractor  for  continued  evaluation  and  use. 
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MODELLING  AND  ANALYSIS 
OF  ENTERPRISE  INFORMATION  SYSTEMS  WITH  CIM-OSA 

F.  Vernadat 

INRIA-Lorrainc.  France 
and  AMICE  Consortium 


INTRODUCTION 

Enterprise  modelling  and  analysis  methods  and  tools  to  support  system  design 
and  to  prepare  system  implementation  according  to  system  requirements  are 
definitively  required  for  the  implementation  of  CIM  systems.  Also  required  to 
achieve  full  system  integration  is  an  integrating  infra-structure,  i.e.  a  soft¬ 
ware  layer  implemented  on-top  of  heterogeneous  operating  systems,  which 

can  provide  a  common  shared  platform  on  which  diversified  system  compo¬ 
nents  (i.e.  information  technology  components,  manufacturing  technology 

components  and  human  operators)  can  be  interfaced  and  through  which 

they  can  communicate. 

The  AMICE  Consortium,  which  groups  21  major  European  companies  in  a 
common  ESPRIT  effort,  is  developing  CIM-OSA,  an  Open  Systems  Architecture 
for  CIM,  to  address  these  requirements.  CIM-OSA  is  made  of  a  Reference  Ar¬ 
chitecture  for  modelling  the  Panicular  Architecture  of  a  given  enterprise 
(or  part  of  it)  and  of  an  Integrating  Infra-Structure  (IIS),  which  is  a  set  of 
basic  services  used  to  achieve  systems  integration  and  communication  built 
on-top  of  OSI-based  communications  facilities.  CIM-OSA  advantages  and  basic 
principles  (Beeckman,  1989),  'Ihe  CIM-OSA  modelling  framework  (Jorysz  and 
Vernadat,  1990a,  1990b)  and  the  CIM-OSA  Integrating  Infra-Structure 

(Klitiich,  1990)  have  already  been  discussed  in  previous  papers. 

The  Modelling  Framework  developed  in  CIM-OSA  is  based  on  three  or¬ 
thogonal  modelling  principles  (Figure  1): 

-  the  instantiation  process  based  on  the  recognition  of 

*  Generic  Building  Blocks  or  basic  constructs 

*  Panial  Models 

*  Particular  Models 

-  the  derivation  process  consisting  of 

*  a  Requirements-  Definition  Modelling  Level 

*  a  Design  Specification  Modelling  Level 

*  an  Implementation  Description  Modelling  Level 

-  the  generation  process  involving  four  modelling  views: 

*  the  Function  View 

*  the  Information  View 

*  the  Resource  View 

*  the  Organisation  View 

Particular  Models  are  models  of  a  panicular  enterprise.  They  can  be 
built  from  previously  defined,  incompletely  instantiated.  Partial  Models 

stored  in  the  CIM-OSA  Reference  Architecture  and  developed  for  well-defined 

industrial  sectors.  Partial  and  Particular  Models  are  specified  in  terms  of  ba¬ 

sic  Building  Blocks,  also  called  modelling  constructs. 

At  the  Requirements  Definition  Modelling  Level  a  user-specified  model 
of  the  enterprise  is  built  which  defines  WHAT  has  to  be  done  in  terms  of 
business  requirements.  At  the  Design  Specification  Modelling  Level  consis¬ 
tent  and  non  ambiguous  models  arc  developed  for  the  four  Modelling  Views. 


A-2. 


They  represent  possible  solutions  to  the  enterprise  problems  and  the  types  of 
components  required.  Design  criteria,  system  requirements  and  simulation 
are  used  to  determine  the  "best"  solution.  At  the  Implementation  Description 
Modelling  Level  an  executable  model  is  produced  which  indicates  HOW  things 
will  be  performed  on  implemented  components  to  fulfil  system  requirements. 

The  CIM-OSA  Function  View  is  a  modelling  standpoint  which  allows  the 
specification,  design,  analysis  and  implementation  description  of  the  struc¬ 
ture,  behaviour  and  functionality  of  the  CIM  enterprise  functions. 

The  CIM-OSA  Information  View  is  another  modelling  standpoint  which 
allows  the  speciHcation,  design,  analysis  and  implementation  description  of 
the  information  aspects  of  the  CIM  enterprise. 

The  CIM-OSA  Resource  View  and  Organisation  View  are  respectively 
concern,,  with  physical  components  and  individual  responsibilities. 

In  this  paper,  we  discuss  how  to  model  the  information  system  of  an  en¬ 
terprise  according  to  CIM-OSA  principles.  However,  since  the  analysis  of  the 
Function  View  of  a  given  enterprise  is  a  prerequisite  to  the  analysis  of  its  In¬ 
formation  View,  we  first  present  concepts  of  the  CIM-OSA  Function  View. 
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Figure  1:  CIM-OSA  Modelling  Framework  (known  as  the  CIM-OSA  Cube) 
CIM-OSA  FUNCTION  VIEW 

The  purpose  of  the  CIM-OSA  Function  View  is  to  provide  tools  and  methods  to 
suppon  the  development  of  that  pan  of  the  enterprise  model  describing  sys¬ 
tem  functional  structure,  functionality  and  behaviour.  It  concerns  modelling 
and  analysis  of  enterprise  functions.  It  is  based  on  the  functional  decomposi¬ 
tion  principle  and  largely  extends  previous  techniques  such  as  SADT  (Ross. 
1977),  IDEFO  (Bravoco  and  Yadav  1985a,  1985b)  and  the  like. 
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Basic  Concepts 


In  CIM-OSA,  any  enterprise  can  be  decomposed  into  a  number  of  Domains,  i.e. 
non-overlapping  subsets  of  the  enterprise  realising  functions  of  the  enter¬ 
prise  in  terms  of  processes  (e.g.  product  engineering,  manufacturing,  pro¬ 
duction  planning  and  control,  etc.).  A  Domain  must  never  be  confused  with 
an  enterprise  department,  which  means  that  CIM-OSA  banishes  the  tradi¬ 
tional  Taylorism  approach  to  enterprise  decomposition  which  has  led  in  the 
past  to  the  creation  of  many  so-called  islands  of  automation. 

A  CIM-OSA  Domain  is  the  part  of  the  enterprise  which  will  be  the  focus 
of  a  CIM-OSA  analysis  (it  defines  the  universe  of  discourse  of  the  analysis).  It 
is  made  of  a  set  of  Domain  Processes,  each  one  contributing  to  the  realisation 
of  some  enterprise  objectives  under  a  given  set  of  enterprise  constraints, 
respectively  known  as  Domain  Objectives  and  Domain  Constraints.  The  scope 
of  each  Domain  is  clearly  identified  by  its  set  of  Domain  Relationships 
(defining  the  Domain  Boundary)  described  in  terms  of  Object  Classes  received 
from  or  sent  to  other  Domains.  Object  Classes  arc  families  of  enterprise  objects 
created,  processed  or  used  by  Domains.  A  Domain  Relationship  is  always  de¬ 
fined  between  two  Domains,  which  are  said  to  be  adjacent. 

Domain  Processes  are  high-level  constructs  used  to  represent  the  major 
tasks  to  be  performed  in  a  Domain.  They  arc  composed  of  Business  Processes 
and  Enterprise  Activities,  which  respectively  describe  the  Domain  behaviour 
(i.e.  the  dynamic  part  of  the  model)  and  the  Domain  functionality  (i.e.  the 
static  pan  of  the  model).  Domain  Processes  and  Business  Processes  arc  trig¬ 
gered  by  Enterprise  Events  which  represent  external  happenings  (arrival  of 
a  customer  order),  human  orders  (decision  to  stan  a  task)  or  timed  actions  (a 
process  is  sianed  each  day  at  5:00  pm)  occurring  in  the  enterprise. 

Domain  Processes,  Business  Processes  and  Enterprise  Activities  (which 
appear  in  the  Particular  Model  of  the  enterprise,  i.e.  the  right-hand  slice  of 
the  CIM-OSA  cube)  and  their  types  (i.e.  Partial  Models)  are  described  in  terms 
of  a  unified  modelling  construct  called  Enterprise  Function  (which  belongs  to 
the  CIM-OSA  Building  Blocks**  i.e.  the  left-hand  slice  of  the  cube).  The  Enter¬ 
prise  Function  construct  (Figure  2)  is  used  to  describe  each  enterprise  pro¬ 
cess,  task,  subtask,  and  so-on  to  a  level  of  decomposition  satisfactory  to  model 
and  control  the  CIM  system  operations.  Thus,  this  modelling  construct  can 
keep  track  of  the  enterprise  functional  decomposition  (structure  pan)  as  well 
as  the  enterprise  Objectives  and  Constraints  decomposition  (which  drives  the 
functional  decomposition  process).  It  also  allows  to  record  Declarative  Rules 
of  the  task  (i.e.  combinations  of  objectives  and  constraints  linked  by  condi¬ 
tions  which  might  influence  the  task  execution).  Procedural  Rules  (which 
describe  the  behaviour  of  the  task,  i.e.  how  low-level  tasks  are  used  to 
perform  that  task).  Events  (which  trigger  the  execution  of  the  task). 

Required  Capabilities  (which  define  a  set  of  technical  limitations  on  the 
operational,  functional  and  performance  capabilities  of  the  task),  and  Inputs 

and  Outputs  (namely  function,  control  and  resource  inputs  and  outputs). 

Enterprise  Activities  (Figure  3)  describe  the  functionality  of  basic  tasks 
which  can  be  performed  in  various  enterprises  (such  as  move,  make,  verify 
and  control)  and  tailored  to  specific  business  requirements  (such  as  pro¬ 
curements,  metal  cutting  or  shipping  and  receiving  activities).  Their  inputs, 
outputs  and  resources  are  well  identified  as  views  of  Enterprise  Objects  (see 

Information  View).  They  operate  according  to  control  inputs,  and  report 

about  their  status  as  control  outputs,  in  order  to  transform  function  inputs 

into  function  outputs  using  resources.  They  are  further  described  in  the 

enterprise  implementation  model  in  terms  of  Functional  Operations .  i.e. 
elementary  sub-tasks  which  can  be  executed  via  the  Integrating  Infra¬ 

structure  by  the  enterprise  components,  called  Functional  Entities. 
Functional  Entities  are  active  elements  which  can  perform  a  defined  set  of 
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Functionar  -Operations.  CIM-OSA  recognises  data  storage,  application, 
machine,  human  and  communication  Functional  Entities  and  Operations. 

Business  Processes  (Figure  4)  are  used  to  describe  the  way  Enterprise 
Activities  are  grouped  into  processes  and  how  activities  and  processes  are 
procedurally  chained  to  form  larger  processes  (such  as  design  processes, 
production  planning  processes,  manufacturing  processes,  etc.)  to  realise  sub¬ 
objectives  of  larger  enterprise  objectives  of  a  complete  Domain  Process. 

The  distinction  between  the  concepts  of  Business  Process  and  Enterprise 
Activity  is  considered  as  very  important  in  CIM-OSA  since  it  is  assumed  that 
what  makes  enterprises  different  from  one  another  is  the  way  they  use  En¬ 
terprise  Activities  to  form  Business  Processes  (this  represents  their  know¬ 
how).  Enterprise  Activities  (such  as  operation  scheduling.  FEM  analysis,  as¬ 
sembly  activities,  robot  welding,  etc.)  are  usually  performed  the  same  way  by 
two  competing  enterprises  and  are  subject  to  standardisation  for  a  well-iden¬ 
tified  industrial  sector  while  Business  Processes  are  not  necessarily  standard. 
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Figure  2:  Enterprise  Function  Concept 
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Figure  3;  Enterprise  Activity  Diagram  Figure  4:  Business  Process  Diagram 


'^Example:  Manufacturing  Workshop  Activity  Control 


Manufacturing  workshop  activity  control  can  be  considered  as  a  Domain  as 

defined  in  the  COSIMA  Project  (Trentin,  1990),  another  ESPRIT  Project.  This 
includes  functions  such  as: 

-  Order  Scheduling  to  schedule  production  activities  on  the  shop  floor  on 

the  basis  of  planned  orders  generated  by  an  MRP  system  and  to  comply 

with  due  dates,  priorities,  availability  of  resources,  etc. 

-  Order  Dispatching  to  send  real  time  instructions  to  moving  and  pro¬ 

ducing  machines  according  to  the  detailed  schedule  produced  by  the 
scheduler. 

-  Producer  Activity  Control  which  controls  specific  types  of  production 
equipment  of  the  workshop  such  as  CNC  machines,  machine  centres, 
robots  and  manual  operations  through  standard  protocols.  It  also  sends 
status  and  performance  data  to  Activity  Monitoring. 

-  Mover  Activity  Control  which  controls  workshop  transport  devices 
such  as  carousels,  handling  robots,  automated-guided  vehicles  (AGVs) 
and  manual  handling  operations.  It  also  sends  status  and  performance 
data  to  Activity  Monitoring. 

-  Activity  Monitoring  is  the  feedback  function.  It  collects  real  time  data 
on  equipment  utilisation,  materials,  stock  status  and  quality  manage¬ 
ment  and  reports  back  to  the  order  scheduler  and  order  dispatcher  or  to 
the  workshop  controller. 

As  an  example,  let  us  assume  that  the  CIM-OSA  Domain  is  a  FMS  producing 
turbine  blades  with  complex  sculptured  surface  for  gaz  turbine; 

Domain:  Workshop  Activity  Control 


Domain  Objectives: 

-  to  produce  turbine  blade^  made  of  aluminum  (max.  weight  1.0  Kg,  max 
length  1.0  m) 

-  to  keep  low  work-in-process  inventories 


-  to  meet  customer  due  dates 

-  to  minimise  lead  times 
Domain  Constraints; 

-  to  maintain  inventory  level  <=  $ 

-  to  work  with  no  more  than  two 

-  cost  limit  (budget  <=  $  700  000) 
Domain  Processes; 

-  Activity  Planning 

-  Activity  Control 

-  Activity  Monitoring 
Object  Classes: 

-  (1)  Planned  Orders 

-  (2)  Parts 

-  (3)  Workpieces 

-  (4)  Machines 

-  (5)  Toolsets 

-  (6)  Batches 

-  (7)  Operators 
Domain  Relationships: 

Rl.  R2.  R3.  R4. 


300  000 
shifts 


-  (8)  Process  Plans 

-  (9)  Materials 

-  (10)  Tools 

-  (11)  Order  Status 

-  (12)  Performance  Reports 

-  (13)  Time  Reports 

-  (14)  Machine  Instructions 


They  arc  described  by  the  diagram  of  Figure  5  showing  the  object  class 
exchanges  between  adjacent  Domains  (Domains  arc  depicted  by  squared  boxes 
with  their  name  inside). 
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Figure  5:  Domain  Relationships 

For  this  example,  Domain  Processes  can  be  further  decomposed  into  Business 
Processes  and  Enterprise  Activities  as  follows: 


DPI;  Activity  Planning  '* 

BPll:  Order  Scheduling 
EAlll;  Plan  Capacity 
EA112:  Allocate  Operations 
EA113:  Schedule  Operations 
BP12:  Order  Dispatching 
EA121:  Analyse  Schedule 
EA122;  Dispatch  Producer 
Operations 

EA123:  Dispatch  Mover 
Operations 


DP2:  Activity  Monitoring 
EA201;  Collect  Data 
EA202;  Report  to  Dispatcher 
EA203:  Report  to  Scheduler 
EA204;  Report  to  User 

DP3;  Activity  Control 

EA301;  Control  Producer 
Operations 
EA302:  Control  Mover 
Operations 


All  these  Domain  components  are  described  in  more  details  in  CIM-OSA  by 
means  of  templates.  As  an  example,  the  Domain  Process  template  is  given  for 
the  Activity  Planning  process. 


DOMAIN  PROCESS 

Identifier:  DPI 

Name:  Activity  Planning 


A.  Functional  Description 

Objectives;  Oil;  to  prepare  the  detailed  schedule  for  daily 

workshop  operations 

012;  to  produce  instructions  for  mover  and  producer 
components 

Constraints;  Cll;  Use  scheduling  program  ABC 

C12;  No  sub-contracted  operations  allowed 


C13:  Produce  with  two  working  siiifts 
Declarative  Rules:  Dll:  scheduling  for  second  shift  must  reschedule 

unfinished  operations  resulting  from  first  shift 
Tasks:  •  schedule  detailed  orders 

-  dispatch  detailed  orders 
Required  Capabilities: 

RCll:  must  be  able  to  schedule  up  to  200  operations  on 
60  machines  in  less  than  15  minutes 


Inputs 

Function  Input: 
Control  Input: 
Resource  Input: 
Outputs 

Function  Output: 

Control  Output: 
Resource  Output: 


Planned  Orders,  Process  Plans,  Standard  Times 
Scheduling  policy 
Scheduling  program  ABC 

Detailed  Schedule,  Mover  Instructions,  Producer 
Instructions 
Activity  Planning  status 
Nil 


B.  Behaviour  Description 

Objectives:  013;  schedule  and  dispatch  detailed  production  orders 

Constraints  C14;  Order  scheduling  precedes  order  dispatching 

Declarative  Rules;  Nil 


Procedural  Rules: 

No.  Wait  For 

Ending  Status 

1.  START 

Order  Scheduling 

Scheduling 

Request 

2.  Order 

done 

Order  Dispatching 

Scheduling 

3.  Order 

abandon 

Order  Scheduling 

Dispatching 

done 

FINISH 

Events: 

EVl:  Scheduling  Request 

C.  Structure  Description 

Where  Used;  Dl:  Workshop  Activity  Control  Domain 

Comprises:  BPll-  Order  Scheduling 

BP  12;  Order  Dispatching 

CIM-OSA  makes  use  of  six  types  of  Procedural  Rules  to  control  the  behaviour 
of  enterprise  processes.  They  include: 

-  Forced  rule:  control  is  passed  to  next  task  irrespective  of  the  ending 
status  value  of  the  finishing  task 

-  Go/NoGo  rule;  is  a  IF  THEN  conditional  statement 

-  Conditional  rule:  control  is  passed  to  a  subsequent  task  selected  from  a 
set  of  possible  tasks  according  to  the  value  of  the  ending  status  of  the 
finishing  task 

-  Spawning  rule;  allows  for  parallel  execution  of  several  tasks 

-  Rendezvous  rule:  control  is  passed  to  next  task  when  all  preceding  tasks 
arc  finished 

-  Loop  rule;  allows  for  iterative  execution  of  some  task(s) 

The  flow  of  control  (Procedural  Rules)  or  the  flow  of  information  and 
materials  (inputs  and  outputs)  of  Enterprise  Functions  can  be  illustrated 
using  symbols  of  Figures  3  and  4.  Figures  6  a)  and  b)  illustrate  the  behaviour 
(i.c.  the  set  of  Procedural  Rules)  of  Domain  Process  DPI  (Activity  Planning) 
and  Business  Process  BP12  (Order  Dispatching).  Figure  7  illustrates  the  flow  of 
information  for  BP12. 
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Nota:  Domains  must  not  be  regarded  as  "islands  of  automation”  since  (1) 
Domain  Relationships  (i.e.  Domain  interactions)  are  clearly  established  and 
specified,  (2)  Domains  must  contain  entire  Business  Processes,  and  (3)  CIM- 
OSA  provides  the  necessary  integrating  infra-structure  to  support  informa¬ 
tion  exchange  between  the  various  enterprise  Domains. 


CIM-OSA  INFORMATION  VIEW 

The  purpose  of  the  CIM-OSA  Information  View  is  to  provide  tools  and  methods 
to  support  the  development  of  the  information  model  of  the  Domains  anal¬ 
ysed.  It  makes  use  of  three  modelling  paradigms,  one  for  each  modelling 
level.  At  the  Requirements  Definition  Modelling  Level,  a  semantic  object-ori¬ 
ented  modelling  approach  is  used.  At  the  Design  Specification  Modelling 
Level,  an  extended  entity-relationship  approach  is  used  which  is  based  on  the 
M*  methodology  (Vemadat  et  al.,  1989).  At  the  Implementation  Description 
Modelling  Level  conventional  data  modelling  techniques  are  used.  The  global 
modelling  framework  is  compliant  with  the  three-schema  approach  proposed 
by  ANSI  (ANSI/X3/SPARC,  1976),  which  advocates  for  the  use  of  a  global  con¬ 
ceptual  schema  implemented  in  terms  of  an  internal  schema  and  presented  to 
system  users  via  external  schemata. 

Basic  Concepts 

At  the  Requirements  Definition  Modelling  Level,  enterprise  requirements  arc 
decribed  in  terms  of  Enterprise  Objects  and  Object  Views.  In  fact,  what  users 
use  and  manipulate  in  their  day-to-day  operations  are  Object  Views  rather 
than  true  Enterprise  Objects,  i.e.  a  description  of  a  panicular  aspect  of  an 
Enterprise  Object.  Furthermore,  we  assume  that  inputs  and  outputs  of  any 
kind  of  Enterprise  Functions  are  Object  Views  only.  Therefore,  analysis  of  the 
enterprise  information  system  must  start  with  functional  analysis  to  identify 
all  enterprise  object  views  and  then  to  derive  the  structure  of  enterprise  ob¬ 
jects.  Both  Enterprise  Objects  and  Object  Views  arc  defined  in  terms  of  their 
Information  Elements,  i.e.  any  items  of  information  which,  for  the  purpose 
they  are  being  used,  are  indivisible  and  which  arc  characterised  by  a  type 
(simple  or  complex  data  type).  Any  kind  of  Integrity  Rules  can  be  defined  on 
values  of  Information  Elements  to  describe  existence,  conformity  or  validity 
constraints.  Enterprise  Objects  arc  connected  to  one  another  by  means  of  Ob¬ 
ject  Relationships,  i.e.  user-defined  links,  or  Object  Abstraction  Mechanisms, 
i.e.  natural  semantic  links.  Four  abstraction  mechanisms  arc  being  used  in 
CIM-OSA  (Pcckam  and  Maryanski,  1986): 

-  Generalisation  (or  ISA  link) 

-  Aggregation  (or  PARTOF  link) 

-  Classification  (or  INSTANCEOF  link) 

-  Association  (or  MEMBEROF  link) 

Graphically  the  model  is  a  semantic  network  in  which  nodes  arc  squared 
boxes  which  represent  Enterprise  Objects  and  oriented  arcs  are  Object  Rela¬ 
tionships.  Object  Abstraction  Mechanisms  arc  arcs  labelled  with  G  for  gener¬ 
alisation,  Ag  for  aggregation,  C  for  Classification  and  As  for  association. 

At  the  Design  Specification  Modelling  Level,  a  Conceptual  Schema  must 
be  defined  as  a  consistent  and  non  ambigous  data  structure  representing 
static  and  dynamic  properties  of  data  and  information.  The  static  part  is  de¬ 
scribed  in  terms  of  an  entity-relaiionship-attribute  (ERA)  model  as  defined  in 
the  methodology  M*  (Vemadat  et  al.,  1989).  This  formalism  is  based  on  the 
concept  of  entities,  relationships  along  with  their  cardinalities,  attributes, 
internal  and  external  identifiers,  and  two  abstraction  hierarchies  which  arc 
special  cases  of  the  ISA  link  (Figure  8).  The  dynamic  pan  is  described  by  (I) 
Database  Transactions  which  arc  sets  of  operations  to  be  executed  on  the 
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database  and  considered  as  a  whole,  and  (2)  by  Integrity  Constraints  which 
are  formal  expressions  of  Integrity  Rules  in  the  ERA  formalism.  Furthermore, 

External  Schemata  must  be  derived  from  the  Conceptual  Schema  to  describe 
the  Object  Views  in  the  ERA  formalism  or  to  specify  detailed  user  views  of  the 
data.  CIM-OSA  provides  translation  rules  to  convert  the  object-oriented  model 
into  an  ERA  model.  The  ERA  model  can  be  fully  formally  described  and  used 
for  simulation  purposes. 

At  the  Implementation  Description  Modelling  Level,  an  Internal  Schema 
of  the  information  system  must  be  described  in  an  executable  form.  This  is 
achieved  by  a  two-stage  process.  First,  a  Logical  Data  Model  is  produced.  This 
is  a  direct  translation  of  the  structure  of  the  Conceptual  Schema  and  its  Ex¬ 

ternal  Schemata  in  ERA  form  into  classical  data  model  formalisms  (relational, 
hierarchical,  network)  (Sec  Date,  1986).  Next,  a  Physical  Data  Model  is  pro¬ 
duced  as  the  final  form  of  the  Internal  Schema.  It  consists  of  an  optimised 
data  structure  of  the  information  system  with  index  definitions,  user  access 

authorisations,  partition  definitions  and  integrity  constraints  specification, 
all  specified  in  the  data  definition  languages  of  the  implementation  data  stor¬ 
age  systems  (such  as  relational  database  management  systems). 

Example 

As  mentioned  earlier,  function  inputs  and  outputs  of  Enterprise  Functions  are 

Object  Views.  For  a  given  Domain,  they  have  been  identified  during  the 
Function  View  analysis.  They  need  to  be  specified  in  the  Information  View 
and  their  underlying  Enterprise  Objects  must  be  described.  As  an  example,  we 
provide  the  description  template  for  the  Enterprise  Object  "Process  Plan"  and 
for  "Opeiine",  a  sub-object  of  the  Process  Plan  object. 


ENTERPRISE  OBJECT 
Identifier;  EO-15 

Name:  Process  Plan 

Description:  Describes  the  sequence  of 

operations  to  manufacture 
the  part 

Abstraction  Relationships: 

Isa:  Nil 

Partof:  Part  Description 

Memberof;  Nil 
Properties; 

Partcode 

Designer 

CreationDate 

Version 

Operations;  Setof  Opeiine 


ENTERPRISE  OBJECT 
Identifier;  EO-I6 

Name:  Opeiine 

Description:  Describes  one 

line  of  a  Process 
Plan 

Abstraction  Relationships: 

Isa:  Nil 

Partof:  Process  Plan 

Memberof:  Nil 
Properties: 

SequenceNumber 

OpeCode 

OpeDcsignation 

MachineType 

SetupTime 

RunTime 

Labour 


All  object  properties  are  either  Information  Elements  or  Enterprise  Objects  or 
a  set  of  (Setof)  Information  Elements  or  Enterprise  Objects.  For  example  the 
Information  Element  "OpeDesignation"  can  be  described  by; 


INFORMATION  ELEMENT 

Name:  OpeDesignation 

Short  Description:  Abbreviated  description  of  a  manufacturing  operation 
Data  Type:  Character  string  [30] 

Related  Objects;  Operation.  Opeiine 

Composed  of;  Operation  name,  operation  instructions 

Synonym:  OpeDcser 


Object  Views  are  incomplete  object  descriptions  and  are  also  defined  in  terms 
of  Information  Elements.  Object  Views  and  Enterprise  Objects  are  then  trans¬ 
formed  into  an  entity-relationship-attribute  model.  Figure  9  gives  an  example 
of  such  a  model  for  workshop  control.  Simple  Enterprise  Objects  (i.e.  objects 
only  made  of  Information  Elements)  are  usually  directly  converted  into  enti¬ 
ties  and  Object  Relationships  into  entity  relationships.  Complex  objects  need 
to  be  converted  into  several  entities  and  their  links  must  be  analysed  care¬ 
fully,  resulting  in  the  creation  of  extra  relationships. 

This  model  can  then  be  translated  into  a  relational  model  using  CIM-OSA 
rules  for  schema  derivation  to  produce  the  Logical  Data  Model  of  the  Internal 
Schema.  A  short  example  of  such  a  model  follows  for  the  schema  of  Figure  9. 

Relational  Logical  Data  Model: 

Part  fpartid.  type,  status,  location,  material.  process_plan_id.  NC_program, 
inspcction_pgm) 

Plan  fprocess  plan  id.  partid.  altemate_plan_id,  particularities,  designer) 
Operation  foperationid.  Opecode,  type,  designation) 

Plan_Ope  (plan  id.  SeqNumber.  Qpeid)  Mach_Ope  (machineid.  opeid) 
ProducerOpc  (Opeid.  Machineid.  Toolid.  cut_type,  setup_timc,  run_time. 

labour,  rate_code) 

MoverOpe  (Opeid.  Machineid.  movetype.  from,  to,  quantity) 

Tool  (toolid.  tool_code,  type,  condition,  location,  tool_lifc) 

Tooling  (tool  code.  tool_raatcrial.  max_spccd,  min_spced,  max_feed,  min_feed. 

max_depth_of_cut,  min_depth_of_cut,  avcrage_tool_life,  tool_geometry) 
Machine  (machineid.  type,  condition,  status,  work_hours) 

Standard_Time  (Opecode.  panid.  machineid.  std_sctup_timc,  std_run_time, 
std_labour) 

Fixture  (fixtureid.  type,  designation,  condition,  location) 

Fixturc_Part  (fixtureid.  partid) 

Part_Fixture  (partid.  fixtureid.  name,  mounting_instructions) 

Lot  (lotid.  partid,  quantity,  jlriority,  status,  duc_datc,  start_date,  fmish.datc) 
Schedule  (cellid.  lotid.  start_date,  finish_date,  priority) 


CONCLUSION 

CIM-OSA  is  a  modelling  framework  and  an  integrating  infra-structure  for 
CIM  environments.  In  this  paper  we  have  introduced  the  Function  View  and 
the  Information  View  of  CIM-OSA  using  a  manufacturing  example.  It  is 
believed  in  the  AMICE  Project  that  the  CIM-OSA  framework  largely  enhances 
previous  modelling  approaches  though  the  Resource  and  Organisation  Views 
are  still  being  engineered.  The  concepts  being  provided  by  the  modelling 
framework  need  to  be  understood  by  the  underlying  CIM-OSA  Integrating 
Infra-Structure  (IIS)  so  that  the  model  can  be  executed.  This  issue  is 
currently  receiving  special  attention  in  the  project  and  demonstration 
prototypes  are  under  development.  CIM-OSA  is  currently  beingconsidered  by 
various  standardisation  bodies  (national  and  international).  Also,  several 
ESPRIT  Projects  are  considering  the  use  of  CIM-OSA  for  modelling  purposes. 

Acknowledgements 

The  author  is  grateful  to  K.  Kosanke,  AMICE  Project  Manager,  and  to  his  AM¬ 
ICE  colleagues,  namely  R.  Caches,  K.  Farman,  H.R.  Jorysz,  G.  Muller,  P.  Rus.sell, 
P.  Viollet  and  M.  Zelm,  who  contributed  to  this  work. 


A- Li 


References 

ANSI/X3/SPARC,  1975,  ANSI/X3/SPARC  Study  Group  on  Data  Base  Management 
Systems,  ANSI  7514TS01. 

R.R.  Bravaco  and  S.B.  Yadav,  1985a.  Requirements  Definition  Architecture  - 
An  Overview,  Computers  in  Industry,  Vol.  6,  No.  1,  pp.  237-251. 

R.R.  Bravaco  and  S.B.  Yadav,  1985b,  A  Methodology  to  Model  the  Functional 
Structure  of  an  Organization,  Computers  in  Industry,  Vol.  6,  No.  1,  pp. 
345-361. 

D.  Beeckman,  1989,  CIM-OSA:  Computer-Integrated  Manufacturing  Open  Sys¬ 

tem  Architecture,  Int.  Journal  of  CIM.  Vol.  2.  No.  2,  pp.  94-105. 

C.J.  Date,  An  Introduction  to  Database  Systems.  4th  Edition,  Addison-Wesley, 
Reading,  MA. 

H.R.  Jorysz  and  F.B.  Vemadat,  1990,  CIM-OSA  Part  I;  Total  Enterprise  Modelling 
and  Function  View,  International  Journal  of  CIM.  Vol.  3. 

H.R.  Jorysz  and  F.B.  Vemadat.  1990,  CIM-OSA  Part  II;  Information  View,  Inter¬ 
national  Journal  of  CIM.  Vol.  3. 

M.  Klittich,  1990,  CIM-OSA  Part  III:  Integrating  Infrastructure,  International 
Journal  of  CIM.  Vol.  3. 

J.  Peckam  and  F  Maryanski,  1988,  Semantic  Data  Models,  ACM  Computing  Sur¬ 
veys,  Vol.  20,  No.  3.  pp. 153-189. 

E. T.  Ross,  1977,  Stmetured  Analysis  for  Requirements  Definition,  IEEE  Trans¬ 

actions  on  Software  Engineering,  SE-3.  No.  1.  pp.  6-15. 

R.  Treniin,  1989,  Production  Activity  Control  (PAC):  Pilot  Implementation  and 
Project  Evaluation.  ESPRIT  89  Conference  Proceedings,  pp.  626-635. 

F.  Vemadat,  A.  Di  Leva,  P.  Giolito.  1989,  Organization  and  Information  System 

Design  of  Manufacturing  Environments:  The  New  M*  Approach,  Com¬ 
puter-Integrated  Manufacturing  Systems,  Vol.  2,  No.  2,  pp.  69-81. 


a)  DPI:  Activity  Planning 


b)  BP12;  Order  Dispatching 


Figure  6;  Flow  of  Control  in  Activity  Planning 


BP  12;  Order  Dispatching 


Figure  7:  Flow  of  Information  in  Order  Dispatching 
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Figure  8;  Entity-Relationsliip-Attribute  Model 
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Preface 


The  [''nterprise  Integration  I'ramework  Study  I'ask  was  performed  hy  IBM  as  a  task  under  the  Control  Data 
(’orporation  DAI’ro  ('ontract  (^r336()0-S7-(.%()464)  for  the  Air  Force  Wright  Research  Dcvclopincnt 
('enter.  I'he  RensscIcaer  Design  Research  Center,  at  Rensselaer  Polytechnic  Institute,  provided  supporliin; 
research  under  subcontract  to  IBM. 

The  objective  of  the  r.If'  Study  task  was  to  ilcfinc  a  national  framework  for  inter  and  intra  enterprise  inte¬ 
gration  based  on: 

•  Open  Systems. 

•  National  and  international  standards. 

I  he  task  was  initiated  in  October  of  l‘)89  with  ;i  meeting  in  Brussels,  Belgium  witli  participants  from  the 
AMICI'  ctrnsortium  in  I'urope  and  representatives  from  the  I  nited  States  tgo\crnment  aiul  I  II  Stiid\  p.'ir- 
ticipanls).  I  he  first  phase  of  the  stndv  included  a  framework  needs  .inalysis,  review  of  the  existinn 
CIM-OSA  and  SliMA  I  l'CII  frameworks,  and  recommendation  for  strawnian  definition  .■Kti\ities  An 
I'literprisc  integratiem  Pramework  Workitig  (innip  was  formed  to  review  the  results  of  the  study  .ic  ti\  ities. 
assess  the  national  framework  needs  from  an  executive  perspective,  and  make  recommendations  to  the  gm- 
emment  sponsors  for  follow-on  actions.  After  at>  initial  I'ill'WCJ  review,  a  second  phase  of  the  simiy  w.is 
initi.'ited,  including  the  initiative  positioning,  scenario  investigations,  ,itul  tei  hnology  inwstigations,  I  he  task 
was  complcteil  in  .Inly  of  1900  with  :i  final  workshop  presentation  at  Dayton.  ()hii>,  I  he  workshop  was 
attended  by  interested  industry  representatives. 

riiis  I'll''  .Study  l  ask  Final  Rep<u1  provides  a  summary  of  the  major  activ  itie;;  petfortned  and  the  resultim: 
fintiings.  The  Final  Report  includes  the  following  sections: 

Kxeciitivc  .Siimniary:  (wuici.se  review  of  backgrouiul,  technical  consiileratnuis,  aiul  conclusions. 

I'cclinical  Siitiniiary:  Describes  the  approach  and  results  of  the  Fill'  stuiiv  aciii  itics. 

Conclusions:  A  summary  of  the  technical  findings  and  recommendations. 

The  following  technical  reports  should  be  referenced  for  additional  information 
KII‘'-\IX9-22  I'lF  Scenario  Investigation 

KII''-.M89-2.3  FIF  Repository  Investig.'ition 

F''.II'’-:M89-24  FIF  l  in.d  VV'orkshop  Brielinu 

l( Fill'  Natiotial  Initiative  Program  Positiomnu 

In  .idditioti,  the  I'ollowinu  documents  which  describe  the  .WIK  1  Computer  Iniv'rr.iled  M.inulaciuiiiie  - 
Open  System  /Xrchitecture  (CIM-DSA)  are  recommended: 

1.  FSPRI  I  ('onsortium  AMICF  teds  ):  Open  System  Architeiture  lor  (  IM.  Vdd  .  Rcse.arch  Repoits 
i  SPRI  I  I’roject  6,S.S, 

2.  (  IM-OSA  Story  BoarrI,  (FSPRI  I  Consortium  A.MICF,  Avenue  I  oni'-e  ■I!s9.  Sth  I  loor.  B-Iu.'^i' 

Brussels.  Belgium) 
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EXECUTIVE  SUMMARY 


The  F.nterprise  Integration  iTaincwork  Study  was  conducted  to  define,  for  nalional  consensus,  a  disciplined 
framework  tliat  would  promote  US  industrial  competitiveness  tlirougli  entcrpiisc  integration.  I  here  are 
manv  projects,  programs,  ;ind  initiatives  that  have  set  out  to  build  this  type  ol  Irarncwork.  I  herefore,  the 
stuily  emphasi/.ed  a  strategy  for  fraincwork  development  by  integration  ol  existing  ellorts  rather  than  inde¬ 
pendently  creating  a  new  one. 

1  he  study  included  four  major  activities: 

1.  Developing  1  he  Needs  Tor  A  I'ramework 

2.  i’ositioning  I'xisting  Initiatives 

.1,  I'valuating  I'ramework  Application 
4.  Investigating  Framework  Supporting  lechnology 

I  he  ncctls  for  a  fr.amework  were  de\  eloped  IVom  a  business  m.inagcinent  aiul  lei  hnical  completeness  per¬ 
spective.  riiere  is  a  torrent  of  boriks  and  articles'  which  provide  lists  of  issues,  di.mnoses,  anil  prescriptions 
for  solutions  to  the  I'.S.  manufacturing  competitiveness.  I  hese  solutions  were  suinmari/cd  into  lice  aciiiuis 
which  an  enterprise  integration  framework  must  support.  These  arc: 

1.  Continually  strive  for  excellence  in  meeting  customer  demands. 

2.  Rapidly  re\ise  or  introduce  new  products  and  technology. 

,F  Cnderstand  and  simplify  every  function  in  the  enterpri.se. 

4.  Dynamically  manage  the  processes  in  the  enterprise. 

.“i.  Manage  an  explosion  of  data,  information,  and  knowledge. 

To  support  the  development  of  a  gcner.il  framework,  these  resulting  actions  must  be  descriistiie  and  not 
specifically  prescriptive.  Also,  the  I'll'  Study  focu.scd  on  the  technical  ;ispccts  of  integration  for  these  actions, 
although  it  is  recognized  that  the  cultural  aspects  are  at  least  as  import.ant.  Fin.-illy.  a  complete  enteiprise 
integration  framework  reiiuires  a  structure  and  methodology  that  supports  the  .'iceunite  description  ol  ,ill 
aspects  of  the  enterprise,  and  is  supported  by  ,ui  open,  heterogeneous,  inleurated  environment. 

The  AMICI'  CIM-OSA  framework  was  accepted  as  the  most  conccptiiallv  complete  of  the  existinu. 
reviewed  initi;itives.  It  is  important  to  note  th.it  CIM-OSA  is  being  developed  by  ,'i  consortium  ot  eomp.i- 
nies  that  include  manufacturinu  (users),  information  technolouy,  .and  system  mteuralion  mdiislries  .NNn.  I'ne 
reference  used  for  CI.M-OSA  w.is  the  C.  S.  Air  Force  Intcur.'ited  Computer  .Aulom.-iled  Manuf.ielurmu 
fI(  ',\M)  privgr.im. 

Figure  1  on  p.aue  2  summ.iri/es  the  Tit'  principles  th.it  ;illow  industry  to  eonliuiialK  since  lor  exeellenee 
;md  become  ,'i  superstar  in  ;i  world-wide  marketplace.  I  hroiiuh  the  use  ol  Releienee  Models,  enieipnse 
modellinu.  the  Ibisiness  Desi  riptive  I  .inuiiage  Descriptive  I  .inuuage.  and  methodolouy ,  an  enlerpnse- e.m 
institute  .1  continuous  evele  to  understand  ;md  improve  the  enterprise  liiiu  lions  Txeeutable  models  .allow 
simulation  so  these  improvements  can  be  introiluced  r.ijvidly  while  reduemu  mierleienee  to  the  enteipiise 
operations.  The  Integrating  Infrastructure  (ITS)  allows  the  enterprise  to  dy  namie.illv  manaue  its  oper.ilions 
through  enhanced  internal  and  external  communications  .iiiil  dynamic  management  ol  enterprise  resniirees 
Targe  volumes  of  data  .ire  described  in  the  models  .and  m.inagcd  through  the  IIS  services  .and  siandard  proto¬ 
cols  in  a  transparent  manner. 


'  tt  (ter  I”  I  tie  It  I  It  I  |(  )<  I  It  \  I’l  I  N  li  t  i  n  pi  eseiil. alive  lIsliiiL'  "I  ...iiii .  es  nvial 
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I  ij;iiro  I.  Kc(iniro(l  Aclioits  ltil(’i>r;ilC(l  Hy  I  ramowork 

I  Ilf  positioning  of  existing  initiatives  sinnmari/eil  the  enterprise  inleuration  Iranieivoik  eharaeleiisiies  alreail\ 
Ix'ing  adilresseil  by  iiHli\'i(lnal  programs,  [  lie  jxisitioning  also  ineliiileil  eolleelivt'  views,  (hat  identi/ied  the 
areas  ofeoveraue,  if  all  programs  were  integraleil.  I  liirteen  (1  'l  eonsensns  initiativ  es  were  rev  iewed.  I  hese 
represented  government  programs,  iiulnstrv  initiatives,  .uid  iiniversilv  progranis  .All  the  initiatives  .address 
•aspeets  of  enterprise  inteiir.ation.  anil  ineliide  overlappine  as  well  .as  uni(|iie  .aspeets  Without  addition.al  inter 
action  between  initiatives,  the  potenli.al  syneruistie  laeiielils  iniiihl  not  be  re.ili/ed.  (  ienei.allv .  the  iiiili.ilnes 
with  the  more  implied,  robust  (-.ipabilities  were  in  (he  eonceptiial  pliase  ol  derinilion.  It  is  important  to 
note,  that  ueneially  it  is  easier  to  .let airnmodate  eh.inges  in  this  earlv  dev eh'pment  periovi:  thus  provulins; 
more  opportunity  to  inlliienee  the  pemling  ilesign  speeiliealions  anil  |irodnets  thiongh  cooperative  inter- 
aetion. 

I  he  application  of  the  Iramcwork  prineiples  depicted  in  l  igiire  I  was  evaluated  through  Scen.ario  Inv  esti¬ 
gations.  The  Scenario  Investigations  were  conducted  m  order  to  identify  a  strawman  framework,  demon¬ 
strate  the  application  ol  framework  eoiieepts.  de|>ict  the  benelils  provided  by  the  Iramework.  and  identify  the 
types  of  tool  re'|uirements.  I  he  Scenaiio  Investigation  Report  includes  a  high  level  summarv  ol CIM-OS A 
concepts  and  Kuhides  an  example  ol  the  aiiplicabilily  ol  ini  l’  to  the  modeling  rei)uiremcnts  ol  (  IM-tlS A 
Ihe  Scenario  Investigation  iiuludes  ,i  I'nterprise  Integration  Roadmaii  .Appliv .ition  (I  IRMA),  this  demon¬ 
strates  how  the  Iramework  concepts  e.in  be  applied  to  an  enterprise  life  cycle.  .Also,  a  life  cycle  methodoloev 
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for  the  creation  of  the  associated  models  and  enterprise  plans  is  described.  I  lic  scenario  investigations 
showed: 

•  Although  the  CIM-OSA  work  is  the  most  comprehensive,  the  support  environment  (modelling  tech¬ 
niques  and  tools)  for  the  life  cycle  methodology  arc  incomplete. 

•  Reference  Moilels  and  standard  protocols  must  I'k;  tlcvcloped  to  build  inter  and  intra  enterprise  inte¬ 
gration  opportunities. 

•  I'hc  realizable  benefits  resulting  from  modeling  arc  limited  since  generally  existing  moilels  ure  not  execut¬ 
able. 


The  Technology  Investigations  included  modeling  evaluations  conducted  by  RIM  RHRC’  and  the  repositori 
investigation.  The  modeling  evaluations  included  a  sample  I'XIM^TSS  (,'IM-()SA  information  model,  mod¬ 
eling  languages  comparison  and  an  enterprise  modeling  evaluation.  I  he  tnotleling  Indicated  that: 

•  Tnterprise  models  require  a  combination  of  process  and  information  models. 

•  The  T.IT'  model  will  be  similar  to  developing  an  extremely  large  software  system,  and  except  for  S  I  T  I’. 
there  is  a  limited  experience  base. 

•  An  "IMT  system  architect"  will  be  essential  to  alTcct  a  solution. 

The  repository  investigation  identified  thirteen  (1.^)  object-managers  that  arc  required  to  provide  a  iKnamic 
information  management  system.  These  managers  can  be  defined  to  be  compatible  with  the  CIM-OSA  Inte¬ 
grated  Infrastructure  requirements.  The  repository  report  identified: 

•  An  open  system  requires  a  self-defining  and  extendable  architecture. 

•  An  object-oriented  approach  could  implement  this  (ipen  systems  capability. 

The  four  major  activities  described  above  provided  technical  definition  for  a  diseij'lined  framework  lor  enter¬ 
prise  integration.  An  enterprise  framework  requires  national  consensus  and  implementations  to  realize 
increased  I  IS  iiulustrial  competitivctiess. 

An  TIT'  Working  (iroup  was  formed  to  review  the  results  of  the  study  contract  activities,  assess  the  national 
framewrrrk  needs  frmn  an  executive  perspective,  and  make  recommendations  to  the  government  sponsors  for 
follow-on  actions.  'The  TIT'  Working  (Jroup  was  comprised  of  industry,  government,  and  uniiersity  repre¬ 
sentatives.  The  workitig  group  reviewed  preliminary  technical  findings  at  three  meetings  (I  ‘>0.  4  'tO  .uul 
.“i/hO).  Teedback  from  the  MT'  Working  (Jroup  was  rellected  in  the  study  ,icti\ities. 

l  inallv,  the  TMT  study  was  directed  toward  defining  ;i  str.awm.in  fr.amewnrk  which  could  be  further  diw  eloped 
through  national  consensus.  A  slniwman  b.iscd  upon  ('l\I-()S,\  w.ts  defined  by  the  scenarii'  and  rcposilori 
investigations.  Recommendations  for  further  development  through  n.ition.al  lainsensus  are  proiided  in  this 
final  report. 

/\  consistent  observation  experienced  In'  the  studied  initi.itives  was  ih.it  e.iininu  consensus  is  a  slow  si.nline. 
tiine  consuming  process.  It  requires  commitment  tow.ard  .i  common  go.al,  .diotment  ol  siilficienl  lime  lo 
incorporate  diverse  perspectives  and  objectives;  plus  it  must  provide  .a  mech.-mism  for  st, ability  .uul  control 
Additionally,  the  Tnterprise  Integration  Tr.amework  represents  ,a  very  complex  system  of  cultural  .aspects  .and 
technical  viewpoints  which  complic.atc  the  consensus  process. 

The  following  recommendations  resulted  from  the  TMT  .Stiiiiv  /Xctivilies: 

1.  Imc>lement  ,a  common  architecture  st.irting  with  the  ('IM-O.SA  definition  Iniairporate  existing  and 
future  OoD  Initi.itives  in  refining,  extending,  and  v.alidating  the  (  1M-()S,\  definition. 

2.  As  a  Test  Case,  develop  a  ic'mmon  l)ol)  Trocurement  I’roccss  description  utilizing. extending  the  TIT 
Roadmap  .and  Methodology  in  .a  consensus  environment.  The  (uirpose  is  lo  pnnide  a  model  li'i  inter 
enterprise  integration  between  the  ( Jovernmenf  .and  nefense  Industrx 
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3.  Plan  incremental  introduction  of  FIT  based  on  requirements  and  tcchnolog)’  capabilities. 

4.  Validate  the  feasibility  of  integrating  existing  information  models  into  a  (.'IM-OSA  reference  model  and 
define  support  tool  requirements. 

5.  Demonstrate  resulting  capabilities  in  selected  DoD  industry'  sites. 

6.  Define  a  D.S.  designated  interface  to  FSPRI  F  AMK.'F,  to  define  the  joint  development  plans. 

Adoption  of  the  F.Il'  principles  means  that  U.S,  industry  can  do  it  better,  less  expensive,  and  faster.  I  hc 
resulting  benefits  are  shown  in  Figure  2.  I'hrough  the  Integrating  Infrastriicture  the  C'hief  I  xecuti\e  DUicer 
((’F-O)  can  enhance  communications  between  his  or  her  team  including  business  partners  ,and  subcontrac¬ 
tors.  I'he  C'FO  can  more  efficiently  manage  the  bu.siness  by  esi.iblishing  metrics  .ind  communicatini'  them, 
along  with  customer  demands,  ,is  objectives  and  con.straints  through  an  integnitcd  planning,  ilevelopment , 
and  operations  environment.  The  engineering  team  can  retlucc  non-v;ilue  adtl  functions  and  rapidly  intro¬ 
duce  new  technology  am!  chanucs  while  lowering  development  costs  ,ind  cycle  times.  I'ntcrprise  operations 
will  become  more  efficient  through  dynamic  m.anagcment  of  resources,  and  transparent  d.ita  atul  communi¬ 
cations  management  allowing  improved  performance  with  reduced  operational  .and  maintenance  c:osis.  I  he 
net  result  for  the  (  FX)  is  an  integrated  team  that  will  improve  cpiality  while  reducing  costs  and  cycle  limes. 


Engineering 

Operations 

e  Triceablllty  to  Obleotlvee 
and  Conetralnta 
e  Rapid  Introduction  of  New 
Tbchnology/Changoa 

•  Reduction  of  Non-Vkiue 

Add  Functions 

•  Lower  Development  Costs 
and  Cycle  Times 

e  improved  Performance 
e  Lower  Maintenance  Costs 
e  Lower  Operational  Costs 

Integrating  Infrastructure 

-  Enhanced  Communloatlons 

-  Efficent  Management  of  Business  Partners 
and  Guboontraotore 

-  Integrated  Plannlng/Develi^mBnt/OperatlonB 

I  igiire  2.  I  ramework  Itrni'lils  In  Applic.ilion 
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TECHNICAL  SUMMARY 


BACKGROUND 

The  coinpetitivcness  of  U  S.  manufacturing  is  a  fundamental  element  of  the  U  S.  defense  posture.  Advanced 
technology  leadership  and  defense  productivity  arc  even  more  critical  for  sustaincii  systems  capabilities  in  an 
era  of  declining  defense  spending.  The  issues  of  U.S.  competitiveness  are  an  industry'  problem,  jointly  being 
addressed  by  industry,  government,  and  universities.  Many  e.xi.sting  programs,  consortiums,  and  initiati\cs 
have  been  formulated  to  address  different  aspects  of  the  competitive  problem.  As  a  result,  many  significant 
recommendations,  technologies,  and  management  approaches  arc  evolving  to  support  the  improved  ecunpel- 
itive  position  of  U.S.  Industry.  However,  a  single  unified  vision  which  inter-relatcs  the  various  aspects  ,ind 
solutions  into  a  common,  consistent,  and  complete  representation  is  not  apparent.  Many  people  already 
recognize  the  need  for  cooperative  development  but  without  a  unifying  vision  the  opportunities  for  cooper¬ 
ation  become  less  apparent. 

I'his  common  need  was  recognized  by  the  DoD  (?AI,S  policy  office,  Wright  Research  and  nevelopmenl 
('enter  (WRD('),  and  the  National  Institute  of  Standards  and  I'echnology  who  acted  as  the  gov  ernment 
sponsors  for  the  IHF  program.  An  Unterprise  Integration  Framework  was  pirstulatcd  as  an  appro.ich  to 
define  the  requirements  for  inter  and  intra  enterprise  integration  in  an  open  environment.  This  framework 
would  provide  a  common  structural  definition  which  could  be  used  to  facilitate  cooperation  between  initi¬ 
atives  anil  identify  areas  where  further  extensions  arc  required.  The  FIF  Siuily  cotilracts  to  define  a 
strawman  linterprisc  Integration  Framework  were  initiated  bv  the  Manulacturini’  I  eehnologv  Directorate 
within  WR  DC. 

Two  Fill'  study  contracts  were  awarded  to  IBM  and  Northrop  Aircraft  Divisioti.  I  he  study  eontraets  repres¬ 
ented  different  perspectives  on  the  FilF'  study.  Fhc  IBM  perspective  was  to  establish  a  framework  (reference 
system)  from  which  the  essential  enterprise  activities  of  (1)  business  understamling  and  simplification.  (2) 
entcrpri.se  modeling,  and  (.f)  information  system  architecture  would  be  consistently  formulated.  1  he  cmitrac- 
tors  and  Air  Force  representatives  conducted  joint  technical  reviews  on  a  quarterly  basis.  Both  contractors 
perspectives  were  supportable  from  a  common  underlying  framework. 

Adilitionally,  an  FIF’  Working  Croup  was  formulated  to  review  the  study  contractor  results  and  make  rec¬ 
ommendations  to  the  Fill'  gov'crnment  sponsors.  Fhc  F'll'WC  included  represent.itives  from  ,\iulerson  (  on- 
suiting,  Boeitig  (,'ommcrcial  Airplane  C’o.,  Deere  &  (.'o.,  Digilial  Fiquipment  ( 'orpor.'ition,  1  SI’RI  I 
Cotisortium  AMK'F,  (ieneral  Motors  (F'DS),  Indu.strial  Fechnology  Institute,  lnternation.il  Burliness 
Machines.  McDonnell  Douglas  Corp.,  Martin  Mariett.i,  M.issachusetts  Institute  of  Fechnologv ,  Noithrop. 
I’ymatuning  Croup,  SFMA  I  FCII,  .South  Carolina  Research  .\uthority  ,  Wesiinghouse  I  lectric  Corp  ,  and 
the  government  spmisors. 

Fhc  AMICF  CIM-Cpen  Systems  Architecture,  an  existing  candid.ite  framevvork,  and  other  Iramewoik  like 
programs  in  the  UkS,  were  evalualeil  in  the  first  phase  of  the  study,  1  his  phase  included  a  summ.uy  ol  the 
needs  for  enterprise  integration,  an  outlitie  of  the  requirements  for  a  fi.imevvork.  and  the  (ormulation  loi  a 
pl;m  for  defining  a  strawman  framevvork.  A  strawman  F  IF'  vv.-is  developed  .and  the  existinu  initiativ  es  posi¬ 
tioned  agains'  that  strawman. 

In  phase  two  the  focus  of  the  FIF  Study  was  on  the  integration  technology  issues,  Althouuh  issues  such  .as 
cultural,  economic,  and  policy  .'ire  significant  to  manufacturing  competitiveness.  t!;e  integr.ition  Iramewiuk 
provides  the  basis  for  an  information  system  reprc.scntation  ot  the  enterprise,  business  management,  iin.mci.il. 
;md  other  issues  that  are  addressable  through  the  capabilities  provided  by  .an  intceration  li.imevvork.  Fhc 
framework  benefits  cannot  be  fully  realized  until  components,  especially  lelcrcncc  models,  of  the  Ir.imcwork 
are  developed. 
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'I'he  study  activities  initiated  with  a  U.S. /AMICE  three  day  meeting  in  Brussels  to  review  CIM-OSA  and 
obtain  documentation.  The  U.S.  group  consisted  of  representatives  from  the  National  Institute  of  Standards 
and  Technology,  the  Manufacturing  I'cchnology  Integration  Technology  Division,  the  Computer-aided 
Acquisition  and  Ixjgistics  Support  (CAI.,S)  office,  and  the  I'lE  contractors'  representatives.  The  main  objec¬ 
tives  of  the  AMICE  project  are: 

•  to  enable  fast,  economic  utilization  of  advanced  technologies  in  industry. 

•  to  ensure  long  range,  evolutionary  CIM  implementation  and  growth 

•  to  enable  and  support  independent  development  of  CIM  building  blocks. 

(/IM'OSA  is  an  emerging  standard  in  the  European  Economic  ('ommunity  and  is  under  consideration  in  the 
International  Standards  Organization.  1  he  conceptual  work  has  been  completed,  but  significant  specifica¬ 
tion,  development,  and  validation  work  is  still  required.  Since  CIM-OSA  is  being  consiilcred  as  an  interna¬ 
tional  standard,  the  U.S.  needs  to  validate  that  C/IM-OSA  satisfies  U.S.  enterprise  requirements.  Wliether 
this  includes  U.S.  cooperation  with  the  AMK^'.  must  be  decided.  The  I  IT  Stiuly  suggests  that  cooperation 
is  required,  and  this  is  rcllected  in  the  recommendations. 

The  I'lT  Study  completed  with  an  end  of  contract  workshop  in  Dayton.  Ohio.  Presentations  uere  provided 
by  the  study  contractors  and  Air  Toree  participants.  A  strawman  TIT  based  on  (  IM-OS/\  was  presented, 
the  findings  from  the  study  activities  were  summarized,  and  the  recommendations  were  reviewed.  An  TIT 
Workshop  Presentation  report  which  includes  the  chart:,  and  the  associated  script  was  prepared,  and  pros  iiles 
a  comprehensive  review  of  the  TIT  Study  results. 

The  following  paragraphs  summarize  specific  aspects  of  the  TIT  study  activities. 


PROBLEM  STATEMENT  /  OBJECTIVES  /SCOPE 

The  Enterprise  Integration  Tramework  (TIT)  task  was  an  effort  to  define  and  develop  for  national  consensus 
a  disciplined  approach  or  framework  that  will  promote  US  industrial  competitiveness  through  enterprise  inte¬ 
gration. 

America's  manufacturing  competitiveness  has  been  the  subject  of  a  torrent  of  books  and  articles.  The  lists  of 
issues,  diagnoses,  and  prescriptions  are  many.  Tlie  list  of  issues  might  include  that  US  industries  must:  lower 
product  cost,  improve  quality,  reduce  inventory',  shorten  lea<!  limes,  integrate  d.ii.i,  ,ind  do  these  on  i  contin¬ 
uing  basis.  Of  course,  each  of  these  issues  generates  its  own  list  of  issues,  di.ignoses,  .ind  prescriptions. 

I  hesc  were  summarized  into  five  categories.  To  remain  in  or  regain  .i  competitive  position.  I  S  iiuiustrics 
must: 

1.  UONTINUAl  lA'  strive  for  TXt'TI  I  T\('T'  in  mecliim  customer  dcm.iiuis,  while  kcepine  the  customer 
view  of  the  recpiirements  in  balance  with  management's  view  ol  the  cnierf'risc  s  mission,  products,  jirot  - 
esses,  and  openiting  environment  (internal  ;iml  external). 

2.  RAIMDI  Y  revise  or  introduce  itevv  proiluets  aiul  RAPID!  Y  inttodiice  nevv  technoU'gies  into  the  prc'- 
diicts  anil  processes  vvilhout  sigtiifieant  impact  to  the  ojH-r.ition  olThe  enterprise. 

.T  I J NDT.R.S'TAND  and  IMPROVE,  every  function  in  the  enterprise,  Ihiough  attention  to  detail  and 
encouragement  of  change. 

4  DYN AMK’AI  I ,Y  MANACJT  the  on-going  set  of  PROUT.SST.S  th.al  are  required  to  oper.ile  the  enter¬ 
prise  and  .accomplish  the  actions  needed  to  achieve  a  competitive  position. 

“s.  \1ANA(iT,  ati  explosion  of  DA  TA,  representing  d.il.i.  inibrmalion,  .and  knowledge  which  describe  the 
internal  and  e.xternal  enterprise  environments. 
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I  hcse  actions  are  applicable  not  only  to  a  specific  enterprise  (intia  enterprise),  but  also  must  be  managed  in 
a  worldwide  competitive  context  including  the  activities  of  customers,  supplieis,  and  trading  partners  (inter 
enterprise).  This  is  particularly  true  in  the  DoD  industry,  where  partnership  development  of  major  weapon 
systems  is  a  requirement.  Inter  enterprise  integration  requires  the  implementation  of  (informatitm )  tech¬ 
nology  that  enables  not  only  the  electronic  integration  and  exchange  of  data  w  ithin  the  enterprise,  but  .dso 
enables  on  a  global  scale  the  sharing  of  knowledge  (meaning,  context,  purpose,  etc.)  regarding  the  tl.tla. 
lixamples  would  include  the  ,S  i  r.l’  ,ind  I'ni  standards  currently  in  development. 

nil'  FRoni  i'M  niA'i  mu.si  nr  answi  ri:d  is  how  io  ni  i  im;,  popi  i  m  i:,  and  i  si 

I  IIP  PRAMP.WORK  rOR  P.N  rpRPRlSI  IN  TI-dRA HON .’  1  his  (luestion  leads  to 

1.  I  IIP,  DI'l'lNl  I  ION  Oh  I  Ills  [' R A.VII’.WOR K.  Is  it  a  method  by  which  business  goals  .and  objeetne 
at  all  enterprise  levels  arc  defined,  connceteil,  etc.,  is  it  .a  siruelurc  in  which  iileas  are  pulled  together  to 
create  something,  or  is  it  an  architecture  (as  definerl  by  the  information  systems  developers),  or  is  it  .all  o 
the  above? 

2.  i  mp:  boundary  DPPINI  I  ion  op  hip  I  RAMPAVORK  I  hal  is,  h^r  the  industrial  enterprise, 
what  .arc  the  major  highest-level  objects  that  are  needed  to  describe  the  cntiapnse  ’ 

.V  hip:  NPX  r  PP.VII  opdi  iaii  i  ii,\  i  is  M  PDPD  lOll  rhiir  dm  ini  mm  hoi  \D\- 

RlfiS.  What  arc  the  major  items  that  arc  needed  to  define  the  highest-le\ el  objects’ 

4.  HIP  RUPIiS,  PROCIiDURP.S,  (il 'IDI  I  IM  S.  S  I  ANDARDS,  etc.  I  IIA  I  ARl  Nl  1  Dl  D  IO 
(iUIDP  HIP,  POPUPAHON  OP  HIi:  I  RAMPWORK. 

5.  SOPlJHONS  THAI  MKill  l  ADDRl  SS  SOMP  OP  I  III  COMPI  11 1  1\  | M  SS  ISSI  I  S  (  fill 
SPI'CIPIC  locus  IS  SOI  U  I  IONS  I  IIA  I  Rl  I  .M  l  K)  DA  I  A  IN  I  I  (iR A  I  ION  i 

As  we  address  the  objective  to  establish  a  reference  enterprise  inlegraticin  Ir.amewauk,  we  must  keep  locus  on 
the  broad  goal  of  establishing  the  capability  to  design,  develop,  integrate.  ,and  if.’ploy  svstems  .and  .ipplie.a- 
tions  that  support  the  untlerstaruling,  objectives,  definition,  .and  oper.alion  of  the  enterprise  in  an  eir.aron- 
rnent  that  supports  electronic  exchange  of  data,  is  physically  distributed,  aiul  heleroeeneous,  and  combines 
both  legacy  systems  and  new  technology  systems.  I  his  implies  the  need  for  a  fr.amework  that  must  support 
(1)  A  set  of  integrated  models  which  clearly  and  concisely  define  the  relationships  of  objects  w  ithin  ,ind 
shared  between  enterprises.  (2)  A  means  to  ileseribe  the  current  enterprise  oper.ational  einironmeni,  the 
desired  operational  environment,  ,and  the  incremental  evolution  migialion  jxilli  I  M  I  he  \.ariet\  ot  tools  .uul 
methods  that  will  be  ncetled  to  imiilement  the  required  svstems  and  .applie.alions.  |4|  \  means  to  \enl\  test 
any  ilecisions. 

I  he  implications  are  that  this  framework  will  help  l->iiiKI  .i  eomjH-titi\e  enterprise  Miroiieh  loini.il  umler- 
st.'inding  of  the  business,  build  .i  basis  for  managing  eonlinu.a!  improceim  iil,  en.ible  re.il-tinie  ulapt.iiion 
(change),  decouple  business  process  eli.inges  from  s\siem  product  de'.elo|Mnent ,  and  inteur.ilc  il.it.i  .\ithm 
(.leross)  enterprises.  I'lie  scope  of  the  fnimework  w.is  lei'ommendeil  to  lx-  deseri|sti\e  Ixiseil  upc'ii  which 
prescriptive  solutions  for  specific  enterprises,  indiistrv  '.eemenis.  or  other  mili.itoi'  solutions  lOuKI  be  pio- 
vided. 

1  he  key  is  to  rceogni/.e  that  peo|rle  are  aildressing  the  jirobleni.  l-'ut  they  aie  loni  -.d  on  dilTerent  kweb  ot  iIk 
enterprise  or  on  specific  solutions  to  issues.  I  hus.  our  objective  I’ccomes  buildinc  the  tojc  level  liamewoik 
tli.it  integrates  the  appropriate  existing  frameworks  and  solutions  We  must  develoj'  lecommeiul.ilioiis  tli.il 
will  allow  the  utilization  ,nid  improvement  of  this  inteurateil  set  of  lianieworks,  accelerate  the  itn|''leitient,i- 
tion  of  solutions  that  will  improve  eonipetitivencss.  and  provide  fiiciis  to  leseareli  and  developmetil 

In  summary  the  framcwoik  must  include: 

I.  Structure  in  the  form  of  ,i  i ()ncec>tual  ileliiiilion  (loj'  level  boundary)  aiui  i  detailed  definition  (models 
and  relationships)  ol  (ibjeels  within  the  framework. 

2  Methods  that  account  lor  the  lile  cycle  considerations  ol  the  enteij'iise  I  hese  include  the  cuiieni  enter- 
[irise  definitions,  tlu’  desiied  enterprise  ilefimlion,  and  the  migration  p.ath 
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3.  Procedures  and  tools  that  allow  for  the  development  of  a  particular  enterprise's  structure  and  models,  as 
well  as  development  of  specific  problem  solutions. 

4.  Methods  and  tools  to  verify/test  decisions  prior  to  their  implementation. 

5.  An  open,  heterogeneous,  integrated  processing  system  which  supports  the  enterprise  engineering  and 
operating  environments  of  tlic  enterprise. 

In  the  future  environment  of  integrated  data  sharing,  this  framework  will  promote  the  improved 
competitiveness  of  IJ.S  industries  only  if  its  concept,  methods,  procedures,  ;inil  tools  .arc  broadly  acccpieil  and 
used  by  industry.  The  competitive  standing  of  each  individual  enterprise  will  he  a  function  of  how  the 
framework  is  applied  toward  solving  the  specific  issues  of  tlic  global  competitive  marketplace. 


EXISTING  INITIATIVE  POSITIONING 


An  initial  review  of  the  framework  elements  contained  within  the  AMK.'l-  (^M-OSA  and  SIMA  1 1(11 
('IM  Architecture  Concepts  (Juide  was  conducted  concurrcTit  with  the  requirements  dcNclopment  (sec  pre¬ 
vious  section).  I  his  review  concluded  both  initiatives  aildressed  the  problem  throuiili  structurcii  dcserijition 
irf  the  enterprise  (model)  and  ,in  open  integrated  system  environment.  I'ithcr  existing  conceptually  delined 
framework  could  be  used  as  a  starting  point  for  a  national  consensus  framework.  An  initial  selection  ol 
(.'IM-OSA  as  a  baseline  resulted.  The  basis  for  the  selection  of  CIM-(),SA  was  its  approach  to  standards 
(ISO)  status  ami  structure  as  defined  in  the  "CIM-OSA "  framework.  I  his  stnicture  was  rcvicucti  .it  tlie  first 
I'lI'Wd.  The  ril  VVCi  supporteil  the  CIM-OSA  structure  (framework)  as  a  starting  point  and  requested 
that  other  programs  be  positionevi  against  it.  1  he  primary  questions  to  1h‘  .inswered  in  the  ]>ositioning  wen- 
domains  of  the  enterprise  being  considered,  technology  consiilercHl.  and  the  level  ol  program  vlcllnition  (Hie 
cycle  position). 

IBM  and  the  Northrop/ OACOM  teams  initially  performed  indepcmlcnt  program  positioning.  I  hese  assess¬ 
ments  were  mavie  through  documentation  review  and  rliscussions  vvitli  initiative  partieip/mts.  ,\t  the  second 
I'H’WCi  meeting  an  initial  review  of  the  positioning  was  presented.  At  the  meeting  the  decision  was  mavie  tiv 
jointly  ''omplcte  the  initiative  positioning. 

/\n  I  ir  National  Initiative  Positioning  Report  was  published  by  DACOM:  this  contains  the  results  o(  the 
joint  stmlv  positioning.  In  the  repiort  the  initiatives  were  positiouevi  Irom  the  following  viewpoints: 

•  flic  fvpes  of  users  within  and  e.xternal  to  the  enterprise  that  the  programs  aiklresseil. 

•  I  he  proviuet  life  cycle  phases  .aiUlresseil. 

•  1  he  enterprise  life  cycle  phases  .iviviressed. 

•  I  he  variety  of  technologies  avidressed 

•  I  he  enterpiise  processes  .and  information  areas  aiUlressed. 

•  I  he  current  level  ol  ilefinition  relative  to  implementation 

/\  total  of  thirteen  initiatives  weiv  rcvievvevl.  ('I\1-()S,\  was  ivlentilied  as  Ihe  initiative  which  incoipor.iteii 
the  most  vinnplete  viewpoint  o(  the  enterprise  as  a  system.  1  his  result  was  subsequently  eouruitieii  Ivy  the 
.Scenario  Investigations.  I  he  major  liiuiings  inchideil: 

•  When  the  composite  viewpoint  of  the  thirteen  initiatives  was  ev.iliiated,  the  majority  oi  tlie  enterprise 
was  .lot  being  addressed 

•  I  here  was  significant  overlap  In  the  areas  In-ing  aililressed  by  the  iiiilialives. 

•  A  number  of  initiatives  were  at  the  conceptual  level  of  delinilion.  If  av  lii'ii  is  taken  viuickiy.  these  pro¬ 
grams  provide  Ihe  best  opportunity  for  cooperative  ilevelopnient. 
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A  summary  of  the  findings  is  included  in  the  (Conclusions  Section  and  cross  re  ferences  to  the  specific  rec¬ 
ommendations  are  given. 

A  finding  from  our  discussions  with  the  program  participants  was  that  the  value  associated  with  consensus 
actions  was  recognized.  However,  the  detractors  for  the  con.scnsus  between  initiatives  arc  time  aiul  resource 
constraints,  current  deliverable  commitments  (contractual  obligations),  and  tin.-  lack  of  a  recogni/ed  common 
framework. 


SCENARIO  INVESTIGATIONS 

fhe  scenario  investigations  were  initiated  after  the  first  ICII'WCj.  I  he  objei  tives  of  the  scenario  invcstiiiation 
was  to  describe  the  r.nterprise  Integration  iTamework  concepts,  their  application  in  an  enterprise  eneinecrine 
environment,  and  any  derived  benefits.  The  scenario  report  was  based  upon  the  Cl.M-OS/X  Ir.imework.  I  he 
report  includes: 

•  .'\  tutorial  on  ('IM-()SA  which  introduces  the  concepts  included  in  the  fnimework  ,ind  the  inteer.iiine 
infrastructure. 

•  A  roadmap  for  using  the  framework  to  evolve  the  enterprise  to  an  open  svsiems  environment  camsistent 
with  the  enterprise  needs  and  objectives. 

•  A  life  cycle  methodology  for  developing  the  necessary  enterpri.se  descriptions  (models),  the  associ:iteii 
framework  elements,  the  purpose  of  each  framework  element,  and  the  rcsultinu  benefits. 

('IM-OSA  incorporates  two  architectures,  an  enterprise  descriptive  architecture  (fr.imework  composed  ol 
models)  and  an  integratcal  data  processing  environment.  The  descriptive  architecture  ilescribes  the  elements 
of  the  enterprise  in  a  proccs.sable  form  (executable  model),  fhe  integrated  data  processing  .architecture  pro¬ 
vides  the  environment  which  supports  enterprise  engineering  (modeling,  simuKition.  and  decision  makinu). 
application  development,  and  the  enterprise  operational  environment.  Various  aspects  of  the  framework, 
their  definitions,  and  the  benefit  of  applying  the  framework  are  shown  in  fable  I  on  pace  III. 
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Table  1 .  Key  Framework  A.spccts 

Attribute 

Description 

Benefit 

Business  Descrip¬ 
tive  [xinguage 

1  he  definition  of  the  aspects  and  their 
relationships  of  the  enterprise  w  hich 
need  to  be  described  to  establish  a 
system  view  '  for  business  management 
and  enterprise  engineering.  Initial  defi¬ 
nition  of  thc.se  aspects  provided  in  the 
IDF  I'  methodology  has  been  exiendeil 
by  ('IM-DSA  (jcncric  Models. 

Flic  tielinilion  of  the  aspects  will  allow 
the  opportunity  for  business  under¬ 
standing,  business  process  simplifi¬ 
cation,  anil  the  sharing  (integration)  ol 
business  activities.  ..\n  initial  focus  on 
data  integration  is  expanding  into 
process  and  activity  integration.  .\  key 
benefit  is  thiims  that  arc  described  will 
be  separately  controllable  and  rapidb 
changed. 

Partial  Models 

riic  completed  descriptions  for  aspects 
enterprises  have  in  common  I  he 
partial  models  can  be  applicable  across 
or  within  an  industry  segment,  and 
provide  the  basis  for  agreements  upon 
which  integration  can  occur.  I'xamples 
would  include  PDFS  and  FiDI  specifi¬ 
cations. 

Flectronic  e.xch.inee  of  data  lias  dem¬ 
onstrated  improved  responsiveness  ,iiul 
qiialily  Process  simplification  and 
increased  inler-dcpendency  between 
enterprise  processes  (equiv.ilent  to  con¬ 
current  enemeerim:)  will  proved  even 
greater  returns  from  a  quality,  cost 
ellectivencss.  .md  responsiveness  sianil- 
poinl  Paidial  models  represent  a 
shared  inve-.tnient  in  defimlion  .md 

resources 

Computer 

/Voccssabic 

A  language  and  associated  integrated 
environment  uhich  captures  the  busi¬ 
ness  descriptions  and  provides  proc¬ 
essing  capabilities  to  support  the 
enterprise  operation. 

.\  seamless  transition,  which  includes 
simulation,  front  Ihe  models  lo  the 
operating  I'nvironment  provides  Ihe 
basis  for  r.ipid  and  cost  effective 
change.  , 

fiir  Repository 

I  he  key  clement  in  the  integrated  envi¬ 
ronment  which  facilitates  operation  and 
integration  within  the  enterprise.  1  he 
three  schema  concepts  of  II.S.S  are 
e.xtendeil  to  enable  dynamic  use  of  the 
framework  and  operation  of  the  enter¬ 
prise. 

A  key  technology  focus  to  facilitate  ; 

open,  heterogeneous,  integrated  envi-  i 

ronment.  1  he  dynamic  features  wall 
preserve  concurrent  oper.ilion  ot  lee.icv 
systems  and  evolvinir  new  teehnoloeies 

I  iu'  ‘iccii.'irio  itivi'sliiJaliiiii  iiiiliiatfs  flint  the  •iiipporl  tiietliod';  .•m<l  tools  lor  the  Ir.imewoik  .ire  iiieoinpleie 
I  he  scenario  iMveslii:alions  ineliuled  .1  itiappim>  of  the  Irainewoik  reijuireil  elemenis  lo  tlie  IP!  I  metluul- 
olouy  ilevcioped  iiy  tlie  Air  (  nrec  project.  .Siunilkanl  iiiiproseinenfs  to  the  IDl  I-  methodologies 

were  suugcsted  as  a  result  ot  this  mappinj’ 

A  significant  concept  is  the  use  of  Relerenee  Morlels.  Rcl'crciwc  models  can  l>e  delined  at  a  requirements, 
ilesiim,  or  implementation  level.  I  hese  moilels  are  iiiteniled  to  laeililate  Imsiness  process  interaction,  con¬ 
sistent  information  ilefinition,  and  idenlillcation  of  common  actisaties;  this  would  support  tsoth  inter  enter¬ 
prise  integration  and  application  development  eHiciencies.  I  he  concepts  and  specilicalions  for  snpporling 
tools  need  lo  he  validated  through  appiic.alion  ol  Ihe  framework. 

1  he  findings  from  the  scenario  invest/gafion  itu  liulcd: 

•  Reference  models  consistent  with  inter  and  ultra  enterprise  integration  at  the  process  le\els  ate  not 
defined. 

•  (ienerally.  available  models  are  not  exei  iitahle 
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•  I'he  methodology  and  support  environment  for  CIM-OSA  needs  to  be  validated  and  additional  tools 
developed. 

A  summary  of  the  findings  is  included  in  the  C.'onclusions  Section,  and  cross  references  to  the  specific  rec¬ 
ommendations  are  given. 


TECHNOLOGY  INVESTIGATIONS 

fhe  technology  investigations  focused  on  enterprise  modeling  and  an  open  system  repository . 

Enterprise  Modeling 

1  he  enterprise  modeling  investigations  were  performed  by  the  Rennselear  Design  Research  (  enter  and 
included  three  activities: 

•  A  sample  portion  of  ('IM-OSA  was  evaluated  by  translation  to  the  I'.XI’RlfS.S  language. 

•  ,'\n  assessment  of  modeling  languages  for  enterprise  informatio\i. 

•  An  assessment  of  the  applicability  of  modeling  languages  to  the  I  II'  life  cycle  methodology  modeling 
requirements. 

flic  conversion  of  a  small  portion  of  the  ('IM-OSA  model  into  liXl’RI'SS  was  founil  to  be  an  enlightening 
and  a  frustrating  process.  It  was  enlightening  in  the  sense  that  it  forced  a  close  reading  of  the  (  IM-(  )S A 
documentation,  and  thus,  led  to  ,a  much  greater  understanding.  It  was  a  frustration  because  m.iny  del.iiN 
were  missing  from  the  (dM-OSA  documentation.  I  he  formation  of  the  I  XI’RI'SS  moilel  iilentilied  gaps  in 
the  (.'IM-OSA  definition,  (  his  result  indicates  that  a  step  in  the  further  devehijunent  of  ('IM-OS;\  should 
be  a  rigorous  application  of  liXI’RI  SS  in  the  (.'IM-OSA  construct  definition. 

I'xisting  information  modeling  technologies  were  compared  to  irlentify  their  respective  e.ap.ibilities.  I  he 
modeling  languages  considered  the  formally  specified  graphic  data  modeling  languages  IDhl  IX  .aiul  NIAM; 
the  informally  defined  graphics  language  suggc.sted  by  .Shlacr-Mellor:  and  the  lorm.ally  specified  textu.al 
programmatic  information  modeling  language  liXI’RliSS.  fhe  liXl’RI'SS  langu.age  is  .a  superset  of  the 
other  languages;  it  supports  the  modeling  of  complex  canistraints;  and  since  it  is  a  pmgrammatic  langu.age.  it 
is  computer  processiblc.  f  rom  the  I’DI  S/S'l  f  I*  experience,  there  is  something  to  be  gained  by  modeling  in 
two  or  more  langu.ages,  as  each  forces  a  dilTerent  viewpoint  onto  the  modeling  process.  If  the  modeling 
language  iloes  not  support  constraints,  then  these  tend  not  to  be  considered,  in  spite  of  the  fact  that  con¬ 
straints  arc  a  vital  ingredient  of  a  complete  and  robust  information  model. 

S  IM’  has  shown  that  multiple  moileling  methodologies  .and  representations  arc  an  aid  to  human  under¬ 
standing  and  improve  both  the  (pi.-ility  and  elficieiuy  of  model  development.  Ilowcscr.  there  must  .dso  I'c  i 
i dear  understanding  that  one  and  onlv  one  ol  the  model  representations  is  the  inastcr  or  legal  form 
S  IM’  has  also  demonstrated  that  the  necessity  lor  computer  poKcssible  represi ailations  It  sclectcil 
I  XI’RI  SS  as  its  master  language,  as  it  was  inherently  processiblc. 

(  IM-OSA,  and  hence  the  I'll',  is  an  attempt  to  ilefine  an  .afchitecture  for  describing  the  aclisilies  of  in 
enterprise.  I  he  architecture  is  baseil  upon  successive  refinement  from  the  most  general  concepts  to  the  \cry 
particular  instantiation  within  a  specific  business  location.  CIM-OSA  has  onlv  really  provideil  a  preliminary 
sketch  of  what  is  to  be  done.  I’erhaps  the  largest  inotleling  clfoil  to  date  is  occurring  within  the 
I’DI'S/S  ff  I’  project.  I  'niike  S'l  f'l’,  which  is  concentrating  on  modeling  the  information  necessary  to  define 
a  product,  I  lf  modeling  also  includes  activity  or  prrrcess  rnorieling  ,is  well  as  the  information  moileling 
fhus  these  two  types  of  models  must  be  integrated,  f  XI’Rf  S.S  can  be  used  lor  activity  modeling,  as  dem¬ 
onstrated  in  the  in  the  sample  portion  discussed  above;  however,  a  processiblc  language  designed  for  this 
purpose  is  likely  to  be  more  elllcient.  An  example  of  aii  existing  activitv  piocessible  language  would  be 
f  stcllc.  f  stclle  was  defined  and  is  used  within  the  OSI  standards  actieitv  to  define  the  trans.iction  nodes  I  o 
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obtain  the  modeling  integration  required  by  lilF  will  necessitate  some  form  ol  modeling  language  and  tool 
integration. 

At  a  somewhat  higlier  level,  developing  ;ui  Id!'  model  will  be  sitnilar  to  developing  an  extremely  large  soft¬ 
ware  system,  with  added  disadvantage  that  there  is  virtually  no  experience  base,  apart  from  S  l  id’.  At  a 
conservative  estimate,  an  Idl'  will  be  at  least  an  order  of  magnitude  larger  that  S  I  I  'I’.  It  will  be  absolutely 
essential  to  have  a  "FIT  system  architect"  to  act  in  the  same  manner  as  a  software  system  architect. 

The  findings  from  the  modeling  investig.ations  included: 

•  An  enterprise  model  is  a  combination  of  process  and  information  models,  ;ind  the  use  ol  an  integr.ited 
form  of  the  FXI’RFS,S  and  Fstclle  languages  may  provide  the  "master  IdF  model  l.inuuages. 

•  Use  other  (e.g.  graphical)  forms  of  model  presentation  for  explanatory  and  developmental  purposes. 

•  There  are  few  tools  available  t(5  modelers. 

•  An  FIF  system  architect  is  required  to  manage  the  complexity. 

A  summary  of  the  findings  is  included  in  the  Conclusions  .Section  ami  cross  references  to  the  speeifie  rec¬ 
ommendations  arc  given. 

Repository  Investigation 

(.'entral  to  the  integration  of  any  enterprise  is  the  bu.siness-wide  sharing  of  inli'rmation  alxuit  the  enterprise 
objectives,  data,  processes,  policies,  ru'es,  pr<Kedures,  resources,  and  organi/.alion.  In  onler  to  iieeiunplish 
this,  a  central  logical  access  to  all  cr'e. prise  data  must  be  provided. 

AlllK)ugh  the  concept  of  a  .itory  is  .accepted  by  the  initiatives  evaluated,  there  is  no  consistent  definition 
of  its  behavior,  functions  ,i.iU  contents.  I  he  I  IF  Repository  Investigation  included  a  review  cd  the  lol- 
lowing  considerations 

1 .  Technology  is.sucs. 

2.  High  Icv'.i  requirements. 

Architecture. 

4.  Applicability  to  ('IM-O.S.A  Integrating  Infrastructure. 

5.  Architecture  vs.  Applicable  Technology. 

/\n  TIT  repository  architecture  b.ised  upon  object-oriented  principles  and  utili/.iim  thirteen  (  I.M  olsjeet  nian- 
auers  to  control  different  chanacteristics  w.as  defined.  This  repository  pro\  ides  for  the  inclusion  ol  leeae\ 
information  systems  and  is  exteml.able  to  incorporate  new  technology  as  it  is  de\eiopi-d.  I  cizacy  information 
is  defined  as  objects  within  the  repository  thronuh  the  use  of  ur.ippeis  I  hese  wrappers  allow  the  Iclmc) 
system  to  interact  with  the  other  objects  within  the  repository.  The  liynamic  .ispect  ol  the  repository  pro¬ 
vides  for  the  execution  ot  enterprise  activities  baseil  on  Iriizgers  within  the  repositi'rv.  The  object  manauer 
objects  are  themselves  described  in  terms  of  the  thirteen  manauers  .allowinu  the  definition  objects  as  well  as 
other  objects  to  be  free  to  chanue  and  evolve.  Ily  providing  for  the  evolution  of  the  repository  as  new  tech¬ 
nology  becomes  available,  the  TIT  repository  truly  is  able  to  grow  and  operate  as  an  open  systems  einiron- 
ment. 

As  described  in  the  Repository  Report,  the  repository  accepts  and  implements  the  CIM-OS/X  concepts,  ,nul 
includes  the  (  IM-OSA  ( Ommnnicalion,  Inlormation.  Trout  Fnd.  and  Mnsmess  Process  Services  A 
summary  of  the  findings  is  im  hided  in  the  Conclusions  Section,  and  cross  refereiv  es  to  the  specific  iccomin- 
endations  are  uiven. 
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CONCLUSIONS 


The  Fnterprise  Integration  Framework  Study  objective  was  to  define  for  national  consensus  a  strawman 
framework  that  would  promote  US  industrial  competitiveness  through  enterprise  integration.  This  strawman 
national  framework  for  inter  and  intra  enterprise  integration  was  to  be  based  on: 

•  Open  Systems. 

•  National  and  international  standards. 

The  five  questions  identified  in  the  Problem  Statement  were  resolved  as  follows  during  the  stutly  contract; 

1.  I'lIF.  DITTNI  FION  OF'  I’llfi  FRAMIiWORK  -  Ihe  framework  must  accornotlatc  all  aspects.  Irom 
definition  of  goals  and  objectives  (by  some  method)  through  the  information  systems  arcliitcctiirc  whicli 
enables  systems  development  to  further  these  objectives. 

2.  rilF  BOUNDARY  DF:FINH  ION  OI  I  IIF:  FRAMFWORK  -  It  was  determined  that  the  (  IM-OS A 
framework  provided  a  complete  definition  of  the  boundaries. 

.1.  rilF  NFX'F  1  FA'FF  OF  OF  1  All.  I  IlAl  IS  Nl  FDliD  If)  1  UR  l  llliR  D1  1  INi:  1111  HOI  NO  \- 
RIFS  -  The  (MM-OSA  framework  extensions  currently  being  devclopetl  by  AMICI’  arc  deliniim  the 
lower  level  boundary  definitions.  A  co-operative  development  activity  with  A.MKT  was  incliuletl  as  a 
recommendation  to  accelerate  and  define  at  an  implementation  level  the  boundary  descriptions. 

4.  I'HF  RUFFS  ....  N'l  F:DI:D  TO  (iUlDF  1  IIF;  F'RAMI'WORK  -  An  outline  of  the  rules,  procedures, 
guidelines,  etc.  were  outlined  in  the  I  IF  Scen.ario  Investigations.  An  ap]n(\ich  to  the  iipen  system 
requirements  for  information  systems  integration  was  outlined  in  the  Repository  Investigation.  Rec¬ 
ommendations  for  the  con.sensus  based  refinement  of  these  and  other  I  IF  lecpiircd  rules,  procedures,  etc. 
are  provided. 

.N  SOUU'I  IONS  ....  OF  I'IIF;  COMPF  rn  IVFNIi.SS  I.SSUF.S  -  The  development  of  reference  models  pre¬ 
sents  an  opportunity  for  l.i.S.  industry  competitive  improvement.  I'he  development  of  a  inter  enterprise 
reference  model  for  the  DoD  acquisition  process  was  recommended  as  a  test  case  for  substantiatim’  the 
benefits  that  could  be  realized. 

The  study  results  concluded  that  a  strawman  was  provided  by  the  ('IM-OS/\  coiuepts;  liowecer.  the  speedi- 
cations  and  supporting  environment  for  CIM-O.SA  are  still  in  development.  I  S  initiatices  are  develojsine 
equivalent  concepts  for  p.arts  of  the  framework:  however,  a  migration  pl.in  lellectiim  convergence  (d  the  con¬ 
cepts  needs  to  be  ilefined.  Ihe  method<d<)gy  for  the  application  of  the  (  IM-OS  A  concepts  was  postid.ited: 
but.  the  FIF  methodology  needs  to  be  refined  through  a  consensus  process,  .and  a  supportine  itdeer.ded  tool 
set  must  be  defined.  One  of  the  tools  concepts,  an  |•II•  Repository,  w.as  desciilied.  I  he  (dijeclue  ol  the 
1  11'  Repository  is  to  enh.ince  open  systems  definition  by  procidini:  :i  dcn.unic  sell-.idapling  meta-siiuclure 
fr.imework.  The  f’lM-OS/N  concepts  are  currently  in  the  iidcrn.dion.d  si.uulards  ['rocess,  .and  no  e<iui\.dent 
(  ,S  standard  is  in  developmeid. 

Ihe  F  IF  Study  confirmed  that  UlM-OSA  could  be  used  as  the  foundation  lot  an  I'nterprise  lideei;dion 
I  r.amew'ork.  I  he  framework  will  rcaiuire  the  ctimpletion  of  the  ('IM-OS.A  specific, 'ttions,  refinemeid  ot  .an 
enterprise  integration  mcihorlology,  development  of  the  engineciing  suppoil  environmetd  (tools),  .and  esi.di- 
lishment  of  compli.ant  reference  models  and  products.  Although  the  compliant  products  and  models  .ire  not 
developed,  industry  and  government  can  begin  using  the  concepts  with  existing  i-ais.ibililies  atnl  mierate  as 
the  compliant  products  become  available.  Initiation  of  the  development  of  reference  moilels,  baseil  on 
('IM-t)SA  compliant  products  atnl  models,  will  provide  a  Ivisis  for  x’.aliilation  of  the  concepts,  refinement  ot 
the  specifications,  anil  (]uantificati('n  of  the  benefits. 

I  he  following  sections  summ.ari/e  the  findings  .and  recommendations. 
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SUMMARY  OF  FINDINGS 

The  following  tables  summari/e  the  findings  from  the  various  study  activities  performed  on  the  I'll'  Study 
Contract.  I'he.se  findings  are  cross-referenced  to  the  recommendations  for  follow-on  actions,  (e  g.  identifi¬ 
cation  of  the  Recommendation  Topic  -  Action  Number  (III-(i)) 

RENSSELAER  DESIGN  RESEARCH  CENTER  REPORTS 


1 INDINC,  FROM  MOI)i:i  JN(;  INVKS I  IC.A  I  IONS 

RKCOMMIN 

DAIION 

MMHF.R 

CriM-OSA  Modeling  Id  limes  More  C.'omplex  Than  POF.S 

III-l 

Integrated  Tool  Set  Not  Available 

I1I-3 

Require  One  [.anguage  As  A  MAS'ITR  l'<5r  C'ontrol 

1II-2 

lintcrprisc  Model  Is  A  (.'ombination  Of  Models 

f-l 

Master  language  May  Vary  With  Model  I'unction  (e  g.  KS  ITI  I,!'  for  PROCI  SS. 
l'XPRi:SS  for  INrf)RMA HON). 

II1-2 

Constraint  Representation  Is  A  ('ritical  Requirement 

IV-2 

friM-OSA  Provides  A  Preliminary  Sketch  Of  What  Is  To  He  Done 

lV-2 

(ising  More  Than  One  .Motlcl  I.eails  Results  In  A  Better  Cnderstaniiing 

I-.^ 

Require  I'lF  SYS  I  P, M  AIU.'IH  I  I'.CT 

I-l 

NATIONAL  INITIATIVE  POSITIONING 


PRFFIMINARY  1  INDINfJS  IN  FIIAVX;  PRKSKM  A 1  ION 

Rl  ( OMMI  N 
DAIION 

NIMBP.R 

Major  Pocus  Information  Analyst  Viewpoint 

1-4 

Customers,  P .xecutives,  1 'sers  Nceiis  I  cast  locus 

II 

less  I  ban  I  l.ilf  Of  1  ntcrprisc  Pxamined 

I-f> 

Design  .iiul  Manufacturing  Process/Information  Most  Oveii.ip 

I- 5 

;ind  Oriz-'ini/nlion  Have  1  iinitcii  ('overage 

II 

Necess.ary  l  echnical  Hreatlth  Recogni/eil  My  Programs 

N  A 

f)niy  CIM-OS/\  P'ncompasses  All  Of  ’lhe  Pntcrprisc 

I 

Broader  Scope  Programs  In  Conceptual  Development 

1-5 

Architectures  Dig  Development  In  Some  I’rograms 

I-l 
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FINDINC.S  IN  JOINT  POSH  IONINCi  RFI’ORT 

RFTCO.MMICN- 

DATION 

NT  MBFR 

Candidates  For  Co-operation 

1-5  i 

1 

(Candidates  For  F'uture  Development 

1-6 

Methodology,  OSA,  Communications  Strong  (Candidates  For  (Co-ordination 

Across  Programs 

1-5  1 

1 

Management  and  Support  I'unctions  Receive  Fitlle  Attention 

1-6  j 

Information  Management  and  Product  Information  Areas  Arc  A  (Common  laicus 

For  Many  Programs. 

1-5 

Majority  Of  1  enterprise  Not  Ilcing  Addrcs.scd 

1-6 

Broader  Scope  Programs  Arc  In  Conceptual  Phases,  Providing  The  Potential  lor 
Increased  (Commonality  If  Action  Is  Taken  Now. 

1-5 

/Xrchitccturcs  Tag  Development  In  Some  Pr<igrams 

I-l 

EIF  SCENARIO  INVESTIGATION 

I  INI)IN(;S  IN  RI  POR  I 

RITOMMIN- 

DATION 

NIMBFR 

Incomplete  FCntcrprisc  Fife  (Cycle  Methodology 
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RECOMMENDATIONS 


The  recommendations  address  refinement  of  the  architectures  and  methodology  of  the  I-nterprisc  Integration 
Framework.  Specific  recommendations  are  made  for  technology  developments  to  address  framework  eon- 
.sistent  tools  and  an  infonnation  repository.  The  recommendations  include  follow  on  actions  for  establishine 
a  US  interface  into  the  pre-norm  international  standards  activity  of  AMKdi  and  through  this  US  interface 
also  establish  a  migration  plan  for  U^S  initiatives  to  provide  the  ba.sis  for  building  national  conscnsvis  con¬ 
sistent  with  international  standards  directions. 

Recommendations  are  included  in  the  following  topical  areas; 

1.  CQNCFPr 

2.  I  F,ST  CASF 

3.  DIWFUOPMFNT 

4.  VAUIDA'F  ION 

5.  dfmonsirahon 
b.  CIM-OSA  AC  TIONS 

I'or  each  topic  the  following  are  provided: 

1.  RFXrO.MMFNDA  TION  -  High  level  statement  of  suggested  ilircctitni. 

2.  WHA  T  ACTION  -  Suggested  specified  actions. 

3.  .APPROACH!  -  A  short  description. 


I  -  EIF  CONCEPT 

RECOMMENDATION 

Implement  a  common  architecture  starting  with  the  CIM-OSA  definili('n.  Incorporate  existim;  and  future 
OoT)  Initiatives  in  refining,  extending,  and  validatinu  the  (.'IM-OS/\  definition. 

ACTIONS 

This  ; ^commendation  can  be  facilitated  by  tlie  followimi  actions; 

1.  Oesimiate  An  Auent  To  lie  The  SVS  I  TM  ARCIITTTC  T 

2.  Achiere  Consensus  On  Tnterprisc  Integration  Roadmap 
.1.  .Achieve  Consensus  On  Methodology  Process 

4.  Ailopt  A  Hiisiness  Oescriptive  I  angtiage 

5.  Oevelop  Role/Relationship  TOr  Fxisting  Programs 

6.  Provide  (iiiidance  To  New  Programs 
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APPROACH 


These  actions  should  include  the  following  considerations: 

•  Fistablish  a  working  relationship  for  the  continued  development  and  refinement  of  (HM-fFSA  with  the 
A  MICH. 

•  Hstablish  a  consensus  based  US  Architecture  Program  responsible  for  execution  of  US  ('IM-OSA  rdlnc- 
ment  activities. 

•  Initial  actions  required  include  refinement  of  the  HIP  roadmap  describing  enterprise  application  of 
CIM-OSA  and  validation  of  the  associated  methodology  process. 

•  Based  on  CIM-OSA  definition  and  CATS  STANDARDS  ROADMAP,  develop  a  joint  .A.MK'I  DoD 
standardization  plan. 

•  Hxisting  program  and  consortium  activities  should  be  incc^rporatcd  into  consolidatcii  approach,  e  g 
assign  specific  standards  to  programs  and/or  consortiums. 

•  Hxisting  programs  can  provide  technology  demonstration  for  rcquircil  concepts,  specific  oulpiils  .as  draft 
specifications,  and  assessment  of  the  applicability  of  technology'. 

•  Future  programs  can  be  defined  to  accelerate  key  technology  and  additional  enterprise  processes. 


II  -  CALS  TEST  CASE 

RECOMMENDATION 

As  a  Test  Case,  define  a  common  DoD  Procurement  Process  description  ntili/.ine  extending  the  1  II 
Roadmap  and  Methodology  in  a  consensus  process  to  provide  a  moilel  for  inler-cntcrprisc  inlemation 
between  Cjovemmcnt  and  Defense  Industry. 

ACTIONS 

This  recommendation  can  be  facilitated  by  tfic  folh)wing  actions: 

1.  Assign  authority  to  .loint  Service  Task  T'orcc. 

2.  Incorporate  Industry  Participants  For  Prime/Major  Subcontractor/Snpplier  Roles. 

V  I^cvelop  Particular  Models,  (icneric  Building  Blocks,  aiuf  Parti.al  Moilels  Applicable  lo  fJoD 

4.  Assign  An  Integration  Contractor  I  o  .Manage  Task  Force  liulustry  P.artieipalion  in  .leeordanee  w  ith  the 
CIM-DSA  and  the  U.S.  Systetn  Architect. 

5.  Document  Strategic  and  Migration  Pf.ans  Based  On  I  he  Above  .Actions. 

APPROACH 

riiesc  actions  should  include  the  following  considerations: 

Initiate  a  CIM-OSA  C.a.se  .Stinly  lo  improve  the  responsiveness  and  concurrency  allowable  in  the  goxernment 
acciuisition  process,  |•valu.•ltc  the  current  government  acajuisition  proces.ses  and  industry  processes  (  \.S-|S) 
which  interface  with  the  government  to  define  .illernate  process  approaches  ( 1  ()-BF)  Result  shotild  pnnule 
advaneeil  definition  (Strategic  Plan)  for  government  and  inilustry  process  integr.ilion  opisortunities  to  aeliKwe 
the  CATS  objectives.  The  next  step  would  be  lo  ilellne  an  Implementation  ( Migi.ition )  Plan. 
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Ill  -  DEVELOPMENT 


RECOMMENDATION 

Plan  incremental  introduction  of  EIF,  through  development  of  consistent  technology  capabilities  in  mod¬ 
eling,  processing  services  and  applications. 

ACTIONS 

rhis  recommendation  can  be  facilitated  by  the  following  actions; 

1.  Develop  A  Detailed  Repository  Architecture  Specification. 

2.  Adopt  A  Computer  Processible  language. 

3.  Build  ('onsensus  On  Tool  Set  Requirements  For  f  he  Methodology. 

4.  Sponsor  An  Advanced  Development  Program  I’o  Demonstrate  An  FIF  Repository  and  fools  Per  Spec¬ 
ification. 


APPROACH 

■fhesc  actions  should  include  the  following  considerations: 

•  Define  a  migration  plan  to  converge  modeling,  data  processing  ser\ices.  arul  applieati(uis  capable  of  using 
the  processing  .services. 

•  Develop  technology  extensions  to  facilitate  the  case  of  implementation  in  three  area.s  starling  imme¬ 
diately: 

1.  Extend  existing  tools,  like  IDIiF,  to  more  completely  model  the  processes,  provide  computer 
proccssable  results,  and  act  as  a  flexible  integrated  tool  kit.  Apply  the  resulting  tools  across  enter¬ 
prise  process  analyses  conducted  for  CIM,  C'F,  CAI,.S,  ’I'QM,  etc..  Incor|>or;itc  moiiei  outputs  in 
computer  processible  fonn  as  basis  for  legacy  integration  and  migration. 

2.  Define  a  computer  processible  language  for  the  above  consistent  with  the  descriptions  required  to 
support  the  moileling  and  enable  data  processing  services  functions  1  vidualc  1  Xl’Rl  SS, 

F.S'i'FFI .F,  ISyC.lI.,  and  otf.crs  to  fonmilale  a  specific  rccommciul.ition  to  be  incorporated  itUo 
CIM-CtSA. 

3.  Develop  a  rep<5sitory  architecture  basetl  on  the  initial  FIF  repository  rcccunmcnd.ition  report.  Ini¬ 
tiate  a  dynamic  repository  technology  development  baseil  upon  ilcmonstratcil  ('DM  technologies. 
Demonstrate  self-ad;ip(ability  features  of  repository  In-  responding  to  new  ,iilcrn;ili\'c  undciiyiui: 
technologies  from  multiple  vcmlors.  Include  the  identification  atid  inlegr.atitm  ol  existing  siaiuiards 
(CIM-DSA,  IRD.S,  FDF.S,  etc.)  and  if  necessary,  ilcvelopment  of  new  stand.inls. 


IV  -  VALIDATION 

RECOMMENDATION 

Validate  I  he  Feasibility  Of  Integrating  Fxisting  Informjition  M<ulels  Into  A  (  IM-OSA  Reference  Model 
And  Define  .Support  fool  Requirements. 
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ACTIONS 


This  recommendation  can  be  facilitated  by  the  following  actions: 

1.  Extend  CIM-OSA  EXPRESS  Definition 

2.  Integrate  PDES,  EIS,  and  DICE.  PPO  Within  CIM-OSA. 

APPROACH 

riicsc  actions  should  include  the  following  con.sidcrations: 

•  Using  the  current  E.XPRE.SS  definitions  from  PDE.S,  E,1S,  and  the  DK'I:  PPO.  integrate  these  motlcls 
with  the  CIM-OSA  constructs. 

•  Validate  the  ('IM-OSA  constructs  and  define  refinements/extensions. 

•  Define  the  PDES  architectural  relationships  with  (HM-OSA,  identify  tool  rcquirctnents,  assess  the  role 
and  effectiveness  of  a  computer  processible  language  using  EXPRESS  as  the  tentative  target,  and  deter¬ 
mine  the  feasibility  and  limitations  as.socialed  with  model  integration. 


V  -  DEMONSTRATION 

RECOMMENDATION 

Demonstrate  Resulting  ('apabilities  In  Selected  DoD  Industry  Sites. 

ACTIONS 

This  recommendation  can  be  facilitated  by  the  following  actions: 

1.  Define  Partial  Model  Eor  DoD/Industry  Use 

2.  Develop  Site  Specific  Particular  Models  Ba.scd  On  Partial  Moilel 
.1.  Implement  Integrating  Infrastructure  (Components 

4.  Perform  Pilot  Operations 

APPROACH 

riicsc  actions  should  include  the  following  considerations: 

•  I'stablish  CIM-OSA  demonstration  environments  consistent  with  the  incremental  release  ot  CIM-OSA 
capabilities. 

•  Develop  a  Migration  pl;m  to  sho  .v  the  evolution  of  the  CIM-OSA  architecture,  data  irroces'^iug  sci\  ices 
specifications,  model  development,  and  compliant  products. 

•  (Conduct  modeling  activity  utilizing  ICIE  Methodology  and  CIM-OSA  Constructs  to  identify  reciuiied 
improvements. 

•  bailor  tools  to  the  defined  (CIM-OSA  capabilities. 

•  Incorporate  infrastructure  ami  application  products  from  multiple  vemlors. 

•  Substantiate  the  benefits  deriveil  during  the  development  and  resulting  from  operating  in  a  (  IM-O.S,\ 
environment. 
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CIM-OSA  ACTIONS 


RECOMMENDATION 

Designate  a  U  S.  interface  who  will  coordinate  the  CI\f-OSA  actions  directed  toward  /WllCI.. 

ACTIONS 

Define  cooperative/co-development  plans  with  a  U.S.  Government  agency  to: 

1.  Improve  availability  of 

•  AiVIKJIi  Restricted  Data 

•  AM  KM'  Published  Data  (Conference  Presentation,  etc.) 

2.  Define  Standards  Plan  and  Strategy 

Provide  Uroad  Rase  of  1  ducation  and  Documentation  for; 

•  Executive 

•  Imtcrprisc  Fngincer 

•  Information  Analyst 

APPROACH 

We  recommend  that  AMKM',  assume  the  lead  in  addressing  the  three  items  that  are  shown.  If  we  are  to 
have  a  successful  start  to  building  a  joint  enterprise  integration  framework,  items  one  aiul  lour  must  be  given 
priority. 

"fhe  (MM-OSA  concepts,  as  arc  the  problems  of  enterprise  integration,  .are  complex  If  cooperation  and 
consensus  arc  to  be  successful,  then  a  broad  audience  must  have  .access  to  ami  umlerstaiul  the  current  state 
and  direction  of  the  ('IM-()SA  definitions  ami  AMICMfs  plan. 

All  of  the  actions  can  begin  to  lie  formed  when  AMIUl-,  in  the  role  of  the  catalyst,  appoints  a  U  S  interface 
and  h.as  a  ilesignaterl  U..S.  rcpresent.itive  with  whom  to  work. 
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ACRONYMS 


AMICE  r.uropcan  (Computer  Integrated  Manufacturing  Arcliitecture  conscirlium.  One  of  the  f  SI’RI  f 
projects. 

(,'IM-()SA  ('omputer  Integrated  Manufacturing  -  Open  System  Architecture.  I  he  result  from  the  ;\MI('l 
consortium  which  is  being  submitted  to  the  International  Standarils  Organization. 

DARPA  The  Defense  Advanced  Research  Projects  Agency 

ESPRI  T  European  Strategic  Programme  for  Research  and  Development  in  Informa'ion  reehnoloey  sup¬ 
ported  by  the  European  C'ommunities. 

ICstcIle  Language  designed  for  specification  of  distributed  concurrent  processing  systems,  utilized  within 
the  communications  protocols  and  serv'ices  of  the  ISO  Open  Systems  Interconneetion  .irchitec- 
turc. 

EXPRESS  language  developed  by  the  PDIvS/SEEP  international  standarils  communits  for  'he  purpose  ol 
information  modeling. 

SEMA  TECH  SEmiconductor  MAnufacturing  I  EX'I biology  is  a  consortiutn  ol  I  S.  semiconductor  manu¬ 
factures  that  sponsors  and  conducts  research  in  semiconductor  manufacturing  technology. 
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Appendix  A.  CIM-OSA  EXAMPLE 


I  he  following  paper  summarizes  the  (.'IM-OSA  rVamework  and  provides  an  example  applieation  of  the  con- 
struets. 


MODFI.MNG  AND  ANALYSIS  Ol'  F.N  I  liRPRISI',  INTORMA  riDN  SVS  l  l-MS  WH  11  (  IM-OSA  (o 
written  by  F.  Vcmadat  and  presented  at  (TIM  liurope  00  ,  Lisbon,  I’ortug.il,  15-17  M;iy  1000. 
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